<!-- Title: 10:56:25  Mon Jul 10 2006 -->
<!-- Crewchief: Jen (MPC) -->
<!-- Op1: Ankush (SPL) -->
<!-- Op2: Satyajit (observing) -->
<!-- Op3: &nbsp; -->
<!-- Op4: &nbsp; -->
<!-- Op5: &nbsp; -->
<!-- Op6: &nbsp; -->
<!-- Notes: -->
Keep taking data, keep an eye on L1, etc.


<!-- Date: Mon Jul 10 11:02:09 2006 -->
<h3>First clock glitch of the week</h3> 
Got paged out of the silicon meeting for b0svx02 not going to halt.  Turns out we had an SRC fatal error (L2A w/o L1A), indication of a clock glitch.  Unfortunately we asked the ace to end the run before we figured this out, and L3 started having problems when we tried to start a new run, so we lost a lot of time.<br> 
When we looked at the clock errors, we saw BX error, not RF error, so it didn't register on the clock module or in RC.  And the CCC did not actually switch to internal mode.  We cleared the errors, config'd everything, and started running again as soon as L3 was ready.<br>
<!-- Author: Jen & Ankush -->
<!-- Comment: Mon Jul 10 16;34;14 comment by...Jose/Ankush/Sebastian -->
I am not sure that the BS error reported by the CCC caused the SRC l2 w/o l1.  Once RC is not longer in activate the CCC BS errors are not longer cleared, so, since there were several minutes betwqeen the l2 w/o l1 and the time the CCC registers were checked the CCC error could have occured after the SRC error. Though something strange was going on, since RC got stuck in the transition to halt (assuming this was not an operator error). <br>
Having the CCC LA (via altera software) working will help debugging these errors, we tried to get this to wrok, but we need a license from Altera for the Quartus II software. 


<!-- Date: Mon Jul 10 19:25:53 2006 -->
<h2>f512 tripped again</h2> 
Paged when f512 started tripping on AVDD Undervoltage again, and the aces couldn't recover it.  I powercycled the wedge a few more times, then turned it on to standby ladder by ladder.  That worked; f512 is holding again.<br> 
If it starts tripping a lot, or we can't recover it, I'll take it back out.  We may want to go down and have a look at in an access (but right now it's not tripping "reliably", so we probably wouldn't learn anything).<br>
<!-- Author: Jen & Satyajit & Ankush & Jose -->
<!-- Comment: Mon Jul 10 19;39;40 comment by...Jen & Ankush -->
Checked out the entry on this supply in the power supply database... turns out this is a supply which used to power f03, but it started tripping on AVDD OverCurrent (which is ~ the same as UnderVoltage to the supply).  We pulled the supply and it was fixed at Prep, then we swapped it in for f51 at the beginning of shutdown.  It loadbox tested fine, but now that it's started tripping it's probably only going to get worse.<br>
This is definitely pointing to a supply problem.  D0 requested a 1.5 hr access at the end of store; we're going to ask Ops to request a 2 hr access.  Since this supply is in NWBB, we should be able to get it swapped in that time.<br>

<!-- Comment: Mon Jul 10 20;31;00 comment by...Ankush -->
actually it's NE Bot-Bot

<!-- Comment: Mon Jul 10 22;35;56 comment by...Jen -->
It just tripped again, but the aces recovered it by themselves on the second try, by going off-standby-on. I told them to make sure and pass that knowledge on to the next aces.  Maybe that way we'll make it through the night.


<!-- Comment: Tue Jul 11 02;55;12 comment by...Jen -->
Yeah, scratch that.  Alice called me after it tripped 3 times in 3 hrs.  It's recoverable but not worth it.  I took it out of the HWDB and asked them to reload CAENvolts.dat and start a new run.
<!-- Comment: Tue Jul 11 07;50;52 comment by...Ankush -->
<p>ACCESS GRANTED: Jim Morgan has granted our 2 hour access request. So the ISL power supply will be swapped.</p>
<!-- Date: Tue Jul 11 00:01:55 2006 -->
e012 AVDD just went pink (below the limits) again (see <a href= 
'http://www-cdfonline.fnal.gov/cgi/elog/elog.pl?nb=2006&action=view&page=479&frame=2&anchor=23:55:56.162'>plot</a>).  I told the ace (Alice) to go ahead and ignore it in IMON for now.  So now e012 and e502 are both ingored.<br>
<!-- Author: Jen -->



<!-- Date: Tue Jul 11 07:48:47 2006 -->
<pre>Offline Monitoring summary of the last week 
                                                                                 
* ADCMon problems: 
 - ADCMon had a problem because the online database access was recently 
turned off for the node where plots for ADCMon was generated. David 
Stuart has fixed the problem. 
 - ADCMon plots still have one more problem now. ADCMon plots are 
suffering low statistics problem because the AC++ jobs that unpack the 
raw data are crashing after processing a few hundred events. David 
Stuart is taking care of this. (Or already fixed?) 
                                                                                 
* Old problems that needed monitoring: 
                                                                                 
IB4W4L2 - low physics tail (due to under-depletion?) 
LB0W5L3 - unbiased? 
IB1W2L2 - Bumps in ADC of chip1,2 
IB4W1L4 - low physics tail 
                                                                                                                                                                 
* New problems: 
                                                                                 
None from offline monitoring. 
                                                                                 
</pre>
<!-- Author: Yuji -->



<!-- Date: Tue Jul 11 09:20:54 2006 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-9041&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-9041  width='300' align='top'></a></td><td><p>Ankush asked me to put this in the e-log (it's also in 
the shift e-log).  Seems a little unusual that SVRAD0 and 
SVRAD3 never fell below the integration threshold; Ricardo 
says this may just be high lum.</p></td></tr></table>
<!-- Author: Steve Hahn -->
<!-- Comment: Tue Jul 11 11;09;40 comment by...Jennifer :-) -->
<pre>Don't forget about the bleed current; I think that this is the case for SVRAD 0 & 3.</pre>
<!-- Date: Tue Jul 11 10:12:17 2006 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-9042&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-9042  width='300' align='top'></a></td><td>This is the test of E1 diamond with high voltage</td></tr></table>
<!-- Author: Charlie Schrupp -->
<!-- Comment: Tue Jul 11 10;13;27 comment by...Charlie Schrupp -->
<pre>Voltage started off, was turned on to 2000V, then turned back to 0.</pre>


<!-- Date: Tue Jul 11 10:35:36 2006 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-9044&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-9044  width='300' align='top'></a></td><td>Diamonds E1, E2, and EM, with EM being the malfunctioning diamond.  High resolution.</td></tr></table>
<!-- Author: Charlie Schrupp -->


<!-- Date: Tue Jul 11 10:36:35 2006 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-9045&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-9045  width='300' align='top'></a></td><td>Diamonds E1, E2, and EM; EM is the malfunctioning diamond.  Low resolution.</td></tr></table>
<!-- Author: Charlie Schrupp -->
<!-- Comment: Tue Jul 11 10;38;04 comment by...Charlie Schrupp -->
<pre>E1 and E2 were at 2000V.  Spikes correspond with shifts from 2000V to 0V, 0V to 200V, and 2000V to 0V again.

EM was at 450 volts, turned off, then turned on, then turned off again.  No change in data collected.</pre>
<!-- Date: Tue Jul 11 10:37:59 2006 -->
Entered in Silicon database: <ul>
<li>Ladder: SB2W2L4 
<li>problem n: 1423 
<li>Status: needs_work
<li>Type: Chip_bit_error
<li>Action: Monitoring
<li>entered by: alscott 
<li>description is: The miracle didn't last, unfortunately.  The bit errors came back in run 211452 (on 2006.02.09) and continued off and on.  Right now (runs 219526-219609) they are on.  Given what Sasha said, that the error rate is ~10% and only seems to be fixed after chopping 10 out of 14 chips in the ladder, I guess we should declare this problem unfixable.  I'll let the detector group make the call--I'm not sure if you guys want to try anything else. 
<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: Tue Jul 11 10:45:29 2006 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-9046&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-9046  width='300' align='top'></a></td><td>E1, E2, and EM again. 
 
The big upspikes in EM (yellow) correspond to voltage being turned on to 450V.  The slight downward bumps corresponpond with voltage being set to 0V.</td></tr></table>
<!-- Author: Charlie Schrupp -->


<!-- Date: Tue Jul 11 10:47:41 2006 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-9047&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-9047  width='300' align='top'></a></td><td>Immediately after phone call requesting EM be set at 100V, saw some slight oscillations.  Big spike probably corresponds to something Ricardo and Rainer did with the cables/diamonds.</td></tr></table>
<!-- Author: Charlie Schrupp -->
<!-- Comment: Tue Jul 11 10;59;40 comment by...Charlie Schrupp -->
<pre>After some time there was another spike and more small oscillations, but I didn't get it captured.  A reverse image of this plot (yellow only) is a good approximation.</pre>
<!-- Date: Tue Jul 11 10:56:22 2006 -->
<center><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-9048&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-9048' width='300'></a><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-9049&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-9049' width='300'></a></center>
<!-- Author: Charlie Schrupp -->
<!-- Comment: Tue Jul 11 10;57;55 comment by...Charlie Schrupp -->
<pre>After small oscillations (barely visible on left of smaller scale graph), two more tests from 0V to 450V to 0V to 450V to 0V.  Larger spikes in transitions from 0V to 450V, small downward bumps during transitions from 450V to 0V.  Also, the voltage seems to drop fairly slowly as reported by ACNET.</pre>



<!-- Date: Tue Jul 11 11:05:24 2006 -->
<center><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-9050&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-9050' width='300'></a><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-9051&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-9051' width='300'></a></center>
<!-- Author: Charlie Schrupp -->
<!-- Comment: Tue Jul 11 11;07;35 comment by...Charlie Schrupp -->
<pre>Final test.  Spike in E1, E2 corresponds to west voltage going from 0V to 2000V.
After E1 and E2 were at 200V, set EM from 0V to 450V to 0V to 450V.  The transitions from 0V to 450V are clear spikes, though not as pronounced as the spikes in E1 and E2, but the ramp down from 450V to 0V is barely noticeable as a small downward bump.</pre>



<!-- Date: Tue Jul 11 11:37:45 2006 -->
Diamond access is finished.Following actions were taken :<br> 
0) The diamond test procedure was simply turning the voltage off, and turning it on again. We expect to see a peak in both cases. <br> 
1) We replaced the CDF diamond A422-10 with the spare diamond A230-03. The output of the test is shown in <a href= 
'http://www-cdfonline.fnal.gov/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=309&frame=2&anchor=10:35:36'> 
 here </a> <br> and <a href= 
'/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=309&frame=2&anchor=10:36:35'> 
here </a> <br> 
 
 
2) Regarding the Poly diamond we untaped all connections, change the two barrels (one in the connection to HV and the other on the signal side) and suddenly we started seeing signals in acnet. 
Cabling connection was not changed and is still the one linked <a href= 
'http://www-cdfonline.fnal.gov/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=301&frame=2&anchor=17:35:01'> 
here</a>. The spikes seen on this diamond can be seen <a href= 
'/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=309&frame=2&anchor=10:56:22'> 
here</a> and are different that the other diamonds. Note the lack of a down spike when the voltage of turned off.  
 
 
 
 
  
<!-- Author: Ricardo, Charly and Rainer  -->


<!-- Date: Tue Jul 11 11:53:22 2006 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-9056&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-9056  width='300' align='top'></a></td><td>this is an abort on June 23, 2006 which we should cross check with the diamonds.</td></tr></table>
<!-- Author: rainer -->


<!-- Date: Tue Jul 11 11:53:26 2006 -->
<h3>Access summary for f512</h3> 
The power supply swap went smoothly.  In just an hour we got the spare ISL supply in and loadbox tested it, everything looked perfect.  When we hooked it up to the wedge, all the ladders went to standby and on with no problems.  BUT... when we turned on the REST of the supplies in the crate, we discovered that all 3 of the ISL supplies downstream of IB5W1 (IB4W0, IB4W1, IB5W5) were showing 0 volts and 0 current on every channel, both low voltage and high voltage!  This immediately smells like firmware problems in the new supply -- somehow it can still talk to the crate, but it's not sending the crate all the right information, so the crate can't talk to the supplies that come after it.  We only had half an hour of access at this point, so we decided just to put back the old supply.<br><br> 
When I brought our spare supply back up to the second floor, I tried putting it in the first slot of our test crate and putting another supply in after it.  Lo and behold, I again see 0 volts and 0 current on the second supply when I try to turn it on.  So the problem is indeed reproducible.  If it really is a firmware problem, it's not fixable at Prep.  The supply will have to go back to CAEN... again.<br><br> 
In short: we achieved nothing.  The old supply is still in for IB5W1, which means we'll have to take f512 back out of the HWDB.  And now we're back in the situation of having NO spare ISL power supplies.<br><br>
<!-- Author: Jen, Ankush, Satyajit, Sasha, Jose -->


<!-- Date: Tue Jul 11 12:20:20 2006 -->
<center><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-9052&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-9053' ></a><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-9054&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-9055' ></a></center>
<!-- Author: Ankush -->
<!-- Comment: Tue Jul 11 12;57;46 comment by...Ankush -->
<h3>IMON plots demonstrating the CAEN weirdness</h3>

<p>The IMON plots above show the strange behaviour when the replacement ISL power supply was put in.  The left hand plot shows the current for f512.  The black is when we switched the supply off.  The blue is when Jen pulled out the CAEN net to test the supply in the collison hall.   Then you can see it switch on and draw current.</p>

<p>The right hand plot shows the current for f400.  The PS module sits next to the module power f512.  You can see it turn off, the time Jen was testing the crate.  Then you can see it going pink form 10:13am to 10:42am as it was reporting zero current.  The period after where is goes black, blue and green and Jen putting the old suuply back in.</p>

<p>so the question is why was the pink not noticed upstairs ?</p>

<!-- Comment: Thu Jul 13 02;21;23 comment by...sasha -->
<pre>My bad... I almost didn't sleep a night before and was very tiered, so I overlooked pink wedges. I expected to see pinkies on f51* because the supply was changed, and completely forgot that all other wedges in the same crate were supposed be to green.  </pre>
<!-- Date: Tue Jul 11 13:30:33 2006 -->
Entered in Silicon database: <ul>
<li>Ladder: IB5W1L2 
<li>problem n: 1690 
<li>Status: needs_work
<li>Type: AVDD
<li>Action: Removed_hdwdb
<li>entered by: amitra 
<li>description is: <p>An access came up and the pwer supply was swapped.  Unfortunatle y the swapped in power supply was also faulty.  So the original was  put back in and so f512 continues. Further details are in the <a href= 'http://www-cdfonline.fnal.gov/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=309&frame=2&anchor=11:53:26'> silicon e-log</a>to be out of the HWDB.</p> 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=ISL&wedge=B5W1&layer=L2">report</a></ul>
<!-- Author: Problem DB -->



<!-- Date: Tue Jul 11 16:31:14 2006 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-9059&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-9060  width='300' align='top'></a></td><td>SVT plot for store 4821, came in with initial lumi ~ 163.  Losses are very low and lookin' good.  SVXMon looks good too.</td></tr></table>
<!-- Author: Jen & Satyajit & Ankush -->


<!-- Date: Tue Jul 11 16:32:31 2006 -->
<h3>Crate 13 spontaneous turn-off</h3> 
A few minutes into data-taking, crate 13 lost communication, appeared to reset itself.  We just turned the power supplies back on and are now back to running.<br>
<!-- Author: Jen, Satyajit, Ankush -->


<!-- Date: Tue Jul 11 18:51:47 2006 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-9061&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-9061  width='300' align='top'></a></td><td> </td></tr></table>
<!-- Author:   -->
<!-- Comment: Tue Jul 11 18;53;46 comment by...Ankush -->
<h3>Curious drop in LOSTPB</h3>

<p>Any drop in losses is always good.  So I was curious to understand what caused this big drop in today's store.  I thought it may be connected to the Tev tunes.  So I recalled Ricardo's TevTunes page.  But you can see these tunes had no effect.</p>

<p><em>curiouser and curiouser</em></p>

<!-- Comment: Tue Jul 11 22;15;30 comment by...ronmoore -->
<pre>Actually, this (and the second one at the right edge of the plot) was related to a routine pbar tune adjustment.  We still need to chat about what/how to plot for the tune changes.  (For example, the scale is WAY too big.  Try 0.575 to 0.595 for the tunes.)</pre>


<!-- Date: Tue Jul 11 23:09:30 2006 -->
<h3>Bias line pinkies</h3> 
So the bias currents for e270 and e380 both decided to do a strange little hop up, down and around, starting at 10:45pm (see plots in <a href= 
'http://www-cdfonline.fnal.gov/cgi/elog/elog.pl?nb=2006&action=view&page=482&frame=2&anchor=22:33:36.310'>main elog</a>).  They are now both holding pretty stable just a little bit above their range.<br> 
This doesn't seem to correlate with anything, and the rphi plots from SVXMon for both ladders look fine, so for now we instructed the aces to just watch them.  We also asked the CO to restart SVXMon so we can look at data collected only since the currents jumped high.<br>
<!-- Author: Jen & Ankush -->
<!-- Comment: Wed Jul 12 01;26;35 comment by...Jen -->
So these stayed pink until the end of store, but they were just barely above the limits.  I biased them again and ran through config, they're back at the usual values.  I also checked the ADCMon data from the last run, it's all good.
<!-- Date: Wed Jul 12 00:09:23 2006 -->
<h2>Rad abort!</h2> 
Store just ended with rad abort at CDF?  More info to come...<br>
<!-- Author: Jen -->
<!-- Comment: Wed Jul 12 01;00;36 comment by...Jen, Ankush, Jennifer, Ulrich -->
So CDF did pull the rad abort, we're trying to figure out why.  Nothing in the detector tripped off, and all of L00 biases with current so no crowbars were blown.  Still investigating...



<!-- Date: Wed Jul 12 05:19:57 2006 -->
<h3>Rad abort: intermediate report</h3> 
Here is the current status of the investigation into the rad abort: 
<ul> 
<li>The beam was aborted at 00:00:54 on the West Outer BLM (E:SVBLA2), one of the BLMs without a bleed current source. All other BLMs do not show any excess of radiation. We have also cross-checked with the <a href= 
'http://www-cdfonline.fnal.gov/cgi/elog/elog.pl?nb=2006&action=view&page=483&frame=2&anchor=03:05:44.957'> 
diamonds</a> close to the BLMs, which did not see any radiation either.</li> 
<li>We were unable to plot the BLM FIFO data, because the data from the West Inner BLM was missing. This is a feature of the new Java GUI. Paul Derwent is investigating the reason for the missing FIFO data.</li> 
<li>The general BLM plots for the time of the abort can be found in the<a href= 
'http://www-cdfonline.fnal.gov/cgi/elog/elog.pl?nb=2006&action=view&page=483&frame=2&anchor=01:13:32.402'> 
main e-log</a>.</li> 
<li>A <a href= 
'http://www-cdfonline.fnal.gov/cgi/elog/elog.pl?nb=2006&action=view&page=483&frame=2&anchor=01:52:56.769'> 
more detailed plot</a> shows the strange behavior of E:SVBLA2: Before the abort, the reading jumps up, stabilizes, and jumps up again, going into saturation eventually. If the reading is real, the system was doing what it was supposed to do, i.e. issuing both a dose alarm and a rad abort.</li> 
<li>The strange behavior continues even after the beam is gone: 
The dose rate jumps up, goes into saturation and falls down again. Paul Derwent identified two time constants: 15 seconds and 90 seconds. None of them is related to anything obvious. Find the plot <a href= 
'http://www-cdfonline.fnal.gov/cgi/elog/elog.pl?nb=2006&action=view&page=483&frame=2&anchor=04:01:33.906'> 
here</a></li> 
<li>The MCR crew showed up in the control room. Marv Olson has exchanged the the pre-amplifier card for the channel in question. Now the channels are being tested with a current source.</li> 
</ul>
<!-- Author: Ulrich & Ankush -->
<!-- Comment: Wed Jul 12 05;42;03 comment by...Ankush & Ulrich -->
All four channels checked out fine with the current source. So we are reasonably sure that everything from the pre-amp to the abort logic works. We have issued a global reset (which worked from E2, but not from the Java GUI, we will mail Paul Derwent about that) and await response from ops to reset the beam permit.

<!-- Comment: Wed Jul 12 05;50;05 comment by...Ankush -->
<p>Beam Permit returned....now we wait to see if the BLMs see anything during shot setup.</p>

<!-- Comment: Wed Jul 12 06:04:20 2006 comment by...Ankush & Ulrich -->
Forgot to mention that the input of the pre-amp is now fed into the MADC (multiplexed ADC), so that the raw current from the BLM tube is logged in ACNET. 

<!-- Comment: Wed Jul 12 06;19;56 comment by...Ulrich -->
And here is where you can find the raw data from E:SVBLA2 in ACNET: T:B0LMA2. More details in the MCR e-log:
<pre>
05:51:05-   We've completed the "plan" for SVX issues. All 4 channels were checked with a test signal (and passed). In addition T:B0LMA2 as been set up as DIRECTLY fed off the BLM chassis (i.e. does not go through C335 card). This parameter is in the datalogger and the snapshot manager. If we have another abort, we should attempt to correlate T:B0BLMA2 and E:SVBLA2 to rule out or confirm the C355 thus also ruling out or confirming the BLM chamber itself. - ollie
-- Wed Jul 12 05:52:14 comment by...ollie --  Currently The Tev abort has been made up. We are waiting on RR to be ready for a shot (est ~1hr) then we will shoot. CDF and D0 have been warned.
</pre>
<!-- Date: Wed Jul 12 05:52:30 2006 -->
<h3>MCR e-log entry about the BLM investigation</h3> 
 
<pre> 
04:14:39-   RE: The Tev 
 
Paul Derwent has been involved w/ this process, since he is knowledgeable about the SVX loss monitor abort system. 
We have a plan of action 
 
# The failure has been boiled down to one of three possible failures The BLM itself in the tunnel 
# The Preamp in the BLM chassis 
# The C335 card 
 
Paul thinks a C355 failure is unlikely. There is nothing indicating the signal wasn’t properly digitized. Unfortunately, though he does not see anything that points a finger specifically at the other two parts either. Based on that here is our plan 
# We are going to replace the Preamp for the BLM (Marv Olsen is on the way in already) 
# It is possible to take a signal right from the Preamp of the BLM chassis to a C290 card to the MADC, 4 channels/parameters are already set up to do that (just not hooked up at this time) 
# If there is another failure, we can correlate the Preamp signal with the C335 (normal) loss monitor signal to rule out (or confirm) the C335 
# Since the Preamp will be new, an identical failure (barring the C335) would indicate the loss monitor failed.  - ollie 
-- Wed Jul 12 04:15:01 comment by...ollie --  Ron Moore has been consutled during this time too. 
-- Wed Jul 12 04:33:31 comment by...ollie --  CDF Si experts have requested that once the work is done, we send a Test signal into into the BLM chassis and verify we get an expected BLM signal. 
</pre>  




<!-- Date: Wed Jul 12 07:04:51 2006 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-9063&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-9063  width='300' align='top'></a></td><td> </td></tr></table>
<!-- Author:   -->
<!-- Comment: Wed Jul 12 07;06;15 comment by...Ankush & Ulrich -->
<h3>BLMs are recording</h3>

<p>Protons were injected into Tev for Proton injection tune up.  You can see the protons injection is seen by the BLMs.  So I guess that shows the BLMs are functioning OK.</p>


<!-- Date: Wed Jul 12 07:24:39 2006 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-9064&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-9064  width='300' align='top'></a></td><td><h3>Final Protons are in</h3> 
 
<p>This is the rate plots of all the final protons.  So the BLMs seem to be recording.</p></td></tr></table>
<!-- Author: Ankush & Ulrich -->


<!-- Date: Wed Jul 12 08:30:37 2006 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-9065&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-9066  width='300' align='top'></a></td><td>SVT Spymon for store 4822, initial lumi ~ 109.  Everything looks good in IMON and SVXMon.</td></tr></table>
<!-- Author: Jen, Ankush, Ulrich, Satyajit -->


<!-- Date: Wed Jul 12 09:01:21 2006 -->
<pre>Again, during the abort the C: disk in the machine downstairs got full and we recorded only 18 channels  and only missed the data of the new BLMS. (We can't live like this; we need to  put the new machine TODAY!). 
That's also the reason the diamonds do not have a step down in current at the moment of the abort. Normally at the abort the digitizers stop running while the data is stored in the C: drive and after that the DAQ systems resumes data taking. After finding the disk is full the program never resumed data taking. 
 
 
</pre>
<!-- Author: Ricardo -->
<!-- Comment: Wed Jul 12 14;05;06 comment by...Ankush -->
<p>Is the PC running windows XP ?  If it is, you can "mount" the data disk on the C:\ drive and avoid the disk full problems.</p>
<!-- Comment: Wed Jul 12 14;05;58 comment by...Ankush -->
<p>....and you have access to the administrator account!</p>
<!-- Date: Wed Jul 12 11:57:58 2006 -->
<h3>Lost the store (not our fault!)</h3> 
Well, according to MCR the vacuum valves at B4 closed, and that's why we lost the store.  :(  Aces already took silicon through coldstart, we're fighting with the gui to get some loss plots but it looks like we may have integrated a bit of radiation.<br> 
Tev plan for now is to investigate vacuum loss and do Tev studies.<br>
<!-- Author: Jen, Mark, Jose -->
<!-- Comment: Wed Jul 12 12;14;28 comment by...Jen -->
I biased L00 just to check -- all show current.


<!-- Date: Wed Jul 12 12:18:27 2006 -->
<center><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-9067&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-9067' width='300'></a><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-9068&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-9068' width='300'></a></center>
<!-- Author: Jose & Jen -->
<!-- Comment: Wed Jul 12 12;20;46 comment by...Jen & Jose -->
Haha!  We figured it out.  Three of the fifos showed nothing.  SVMFA2 shows a high level, and then a rising peak before the abort.  Is this real?

<!-- Comment: Wed Jul 12 12;27;27 comment by...Ulrich -->
That is what I say! It looks like the data from SVMFA2 is from last night, when that channel pulled the rad abort. I will inform Paul Derwent about this.

<!-- Comment: Wed Jul 12 12;54;00 comment by...Ulrich -->
Just got the confirmation from Paul that what we see on the plot is a case of lost pointers rather than high radiation. He is working on a fix.




<!-- Comment: Fri Jul 14 08;58;28 comment by...Ricardo -->
To see the 20 us buffer info from the inner tracking diamonds look <a href=' 
http://www-cdf.fnal.gov/~cschrupp/internal/diamond_plots/#7_11_2006__23_57_45_ETD_Zoom'> 
 here </a> and for the new BLM system look <a href=' 
http://www-cdf.fnal.gov/~cschrupp/internal/diamond_plots/#7_11_2006__23_57_45_BLM_Zoom'> 
 here </a>

<!-- Date: Wed Jul 12 14:51:18 2006 -->
<h3>More on the faulty ISL spare</h3> 
This morning I tried swapping the proms between my two ISL supplies, to check if the problem with the ISL spare we tried to swap in yesterday was a firmware problem.  Well, the problem stayed with the supply and not with the prom.<br> 
I consulted with Reid, who suggested looking for any jumpers that CAEN might have forgotten to change for normal running.  So I started doing a detailed visual inspection between my two ISL supplies.  And finally, I found something!  One of the tiny little resistors leading up to one pin of the backplane connector was broken clean in half, with one half still attached to the board and the other half dangling by one soldered side.<br> 
So I took the supply over to Hank at FCC, and he said they definitely could fix that, although he wasn't sure they had any resistors that small around, so he might have to order one.  I don't have any definite proof that this is the cause of this power supply's "issues", but it seems plausible.  And if replacing it doesn't fix the supply, we'll start looking it over for something else!<br>
<!-- Author: Jen -->


<!-- Date: Wed Jul 12 15:36:35 2006 -->
<h3>D0 Access tomorrow (Thursday) ?????</h3> 
 
<p>We may or may not have a 2 shift access tomorrow. Honestly, that is the best answer I have.  Check out the mail sent to all the detector SPLs...so be possibly ready for a long access tomorrow</p> 
 
<pre> 
Hi All: 
   Bill Lee of D0 called me at about 1515 hrs. He says their calorimetry LVDS power supply is still holding and has not tripped. So, he has told Jim Morgan that they may not go in tomorrow at 0700 hrs, but reserve the right to change their minds and go in at 0700 hrs if the power supply trips off again. They will have their access crew on standby and ready for an access at 0700 hrs tomorrow. He also said that Jim Morgan, will probably try to put in a store tonight at 2400 hrs. 
   We should be prepared for an access tomorrow at 0700 hrs. However, the access might not happen, so please check the AD Run Coordinator elog for updates. 
                                                        -- Willis 
</pre>
<!-- Author: Ankush -->
<!-- Comment: Wed Jul 12 17;53;05 comment by...Ankush & Ulrich -->
<h3>The tentative plan</h3>

<p>If the D0 access does take place on Thursday, this is the approximiate order for the Silicon plan:</p>

<ol>

<li><b>Cooling</b>
<p>People: Ulrich, Jennifer + Cryo techls</p>
<p>The Conductivity probe for ISL needs replacing.  Unfortunately, this requires turning off the whole detector.</p>
</li>

<li><b>DAQ</b>
<p>People: Mark + Sebastian</p>
<p>BUSY TO investigation, CCC work, etc.  Some of this work may require power-cycling the SRC crates.  This should be done when the detector if off ie:- during the cooling work.</p>
</li>

<li><b>ISL Power Suuply</b>
<p>People: Jen + 1</p>
<p>Try to replace the power supply for f512.</p>
</li>

<li><b>BLM Visual Inspection</b>
<p>People: Ulrich + Jose</p>
<p>As we pulled the first false Tev abort last night, we should check the West Side BLMs.  If necessary, we may pull the BLM out for inspection by Marv Olson (AD BLM expert).</p>
</li>

<li><b>Quiet Time studes, Fibre-swaps,etc</b>
<p>People: Ankush +1</p>
<p>Check the problem DB, etc.  See if there are ay ladders which need investigating both from the control room and the collision hall.</p>
</li>

</ol>

<p>The cooling will be the first to start as this requires the Cryo techs.  As this requires the detector to be off, the DAQ work which requires powercylcing the SRC crates can take place.</p>

<p>After the cooling work is complete, the next priority is to replace the f512 power supply.  In the mean time, the remaining tasks can place at the same time, with some cooperation between the different sub-groups.</p>

<p>So if the access does go ahead, be prepared to be called in!!</p>
<!-- Date: Wed Jul 12 17:41:32 2006 -->
<h3>Trick to get BLM Abort Data</h3> 
Currently, the Java GUI has a problem with plotting the abort data. Due to some missing data from the abort last night, the GUI displays data from the wrong abort for some of the BLMs. While this is being fixed, here is a work-around which I got from Paul Derwent: Select a time range starting after the abort last night (e.g. 07/12/07, 01:00:00) and ending after the abort in question, pick the abort time in question, and only then plot the FIFO data.  
<!-- Author: Ulrich -->



<!-- Date: Wed Jul 12 18:17:49 2006 -->
<h3>About clk speeds</h3> 
 
 
Steve N pointed that part of our timing problems may be related to  
the different sys clk speed on the mvme after the kernel upgrade. 
Looks like we can set the clk speed in the teststand, so tomorrow, if we have the oportunity we (Mark, Jose and I) can test this  
on a svx crate. 
  
<!-- Author: Sebastian -->


<!-- Date: Thu Jul 13 01:44:35 2006 -->
<h3>Store 4825 ongoing</h3> 
Store came in at ~00:45 with initial lumi ~ 67.  I'm watching from home, and gave permission to bias silicon after talking with Alice and seeing the ACE plots.  But we have yet to start taking data (thanks to L3/EVB it seems...)<br>  
<!-- Author: Jen -->


<!-- Date: Thu Jul 13 02:11:17 2006 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-9069&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-9070  width='300' align='top'></a></td><td>Finally!  Just as I was about to give up and go to bed, they got a run started.  Everything looks good.</td></tr></table>
<!-- Author: Jen -->
<!-- Comment: Thu Jul 13 03;37;57 comment by...Jen -->
We've seen some spikes in pbar losses; the aces called MCR to ask what was causing those, and they admitted to some "small tune changes".  So far they've all been very small (~2 kHz spikes) so they kept running and didn't page me about them.

<!-- Date: Thu Jul 13 03:34:18 2006 -->
<h3>SVXMon having problems</h3> 
Apparently SVXMon has been having difficulties since they started running.  The CO restarted it once already, because it couldn't open up a display.  Now that it is displaying, the CO slides for cell id look fine but the chip status ones are almost entirely red (see <a href= 
'http://www-cdfonline.fnal.gov/cgi/elog/elog.pl?nb=2006&action=view&page=486&frame=2&anchor=03:16:59.930'>main elog</a>).  I checked the SVXMon ntuple, checked a few strip plots, and those look fine.  So I recommended restarting SVXMon again.  I don't know what else could cause a problem like this!<br>  
<!-- Author: Jen -->
<!-- Comment: Thu Jul 13 03;42;47 comment by...Jen -->
Restarting didn't help.  Since it does seem to be working (and I'm all out of ideas, or maybe that's the lack of sleep talking), I said to leave it as is and we'll check it in the morning.


<!-- Comment: Thu Jul 13 06;29;08 comment by...Ankush -->
<p>Just used B0AC++Dump to look at the raw data.  Here is a dump for e000 to e004.  All the ladders terminate with c1c1 except for e004. If you look at further ladders, a lot of them terminate with c1c1. </p>

<pre>
      328: 00003cdf 00003d19 00003d4e 15fde000
      332: 00f38322 690c68f3 6d066a06 6f126e0f
      336: 822270f3 39f3a122 3b043a21 7ff3a022
      340: e001c1c1 852215fd 420200f3 443c4329
      344: 84224506 14f38322 161b1511 18f3170b
      348: 7207a222 7419731f a12275f3 7003a022
      352: 7206712d c1c17ff3 15fde002 00028922
      356: 87228822 85228622 52095101 541f5313
      360: a4225506 6c096b01 6e306d1c 70026f0b
      364: a222a322 a022a122 520a5103 54105313
      368: 5604550f c1c17f02 15fde003 00f38922
      372: 87228822 85228622 a3228422 a122a222
      376: 7401a022 7607750b c1c17ff3 15fde004
      380: 00f38d22 8b228c22 89228a22 87228822
      384: 2fe52ef3 31083003 33ee3215 35083427
      388: 22f3a622 24032309 2601a522 2803270a
      392: a322a422 a122a222 2df3a022 2fde2e0c
      396: 311030f0 33f33209 c2c23ff3 15fde010
</pre>

<p>If SVXMon error was true and all the Z sides were having problems, you would see the errors in the raw data. As this quick glance of the raw data looks OK, I think Jen is right....SVXMon is acting weird.</p>


<!-- Date: Thu Jul 13 06:31:21 2006 -->
<center><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-9071&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-9071' width='300'></a><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-9072&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-9072' width='300'></a></center>
<!-- Author: Ankush -->
<!-- Comment: Thu Jul 13 06;33;54 comment by...Ankush -->
<h3>SVXMon for run 219789</h3>

<p>The Cell ID maps for SVXMon are OK.  But the chip status for the whole detector appears to be having problems. However a quick glance at the raw data suggests the ladders are OK....very odd indeed.</p> 

<!-- Comment: Thu Jul 13 07;41;44 comment by...Jen & Satyajit -->
Error logger says something about SVXMon heartbeat missing.  Satyajit says it looks like the error receiver didn't connect like it should have.  He's looking through the logfile now.<br>


<!-- Comment: Thu Jul 13 09;28;03 comment by...Jen, Satyajit, Ankush, Mark, & Charles -->
<h3>Solution: Cosmics mode</h3>
Turns out ConCon was lying when it said the consumer was in Physics mode, checking the tcls showed ALL consumers were really stuck in Cosmics.  See entry in <a href=
'http://www-cdfonline.fnal.gov/cgi/elog/elog.pl?nb=2006&action=view&page=487&frame=2&anchor=09:19:49.229'>main elog</a>.  Everything is back to green now that SVXMon has been restarted in Physics mode.<br>



<!-- Comment: Thu Jul 13 10;06;25 comment by...Ankush -->
<h3>Q: Why does COSMICs always show SVXMon cells to be red</h3>

<p>Whenever we have run SVXMon in COSMICS mode, we have always seen red cells in SVXMon.  As far as I know, the argument has been the COSMICs rate is too low.  Now, the SVXMon experts can correct me, the only difference between COSMICs and PHYSICS mode is we look at all streams in COSMICs.</p>  

<p>Due to today's little incident, we now have an example of the SVXMon running in COSMICs mode with beam in the Tevatron. So the rates should now be high enough.  Yet the cells are still red. So I don't think the rates argument is valid.</p>

<p>Can a wise SVXMon expert bestow his/her wisdom upon us.</p>



</p>
<!-- Comment: Thu Jul 13 15;16;56 comment by...Mark -->
Well, the Chip Status Map is basically generated by breaking the detector up into like groups of chips (type, layer, dps setting, etc.) and then checking to see if chips deviate from the average of the group and by how much for quantities such as charge and ocuppancy.  Chips that deviate too much are marked as red.  Without digging into the code, I am not sure why the presence of multiple streams (the only difference in Cosmics mode) would affect this map.
<!-- Comment: Thu Jul 13 15;31;32 comment by...Mark -->
Could be that certain quantities that it is looking at, such as chip occupancy, vary much over different triggers and hence physics streams.  Maybe streamD was chosen for physics data because it has reasonable distributions for the quantities of interest.
<!-- Date: Thu Jul 13 07:44:18 2006 -->
Silicon went to standby this morning at 7am, as the CLC PC needed rebooting and we didn't have luminosity data in the meantime.  As soon as the PC was back up I gave permission to bias silicon again, we're back to running.<br>
<!-- Author: Jen -->


<!-- Date: Thu Jul 13 09:12:07 2006 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-9073&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-9074  width='300' align='top'></a></td><td>The bias current for f421 is just BARELY excursioning above its limit.  Ignore it for now, look at currents and up the limit if necessary.</td></tr></table>
<!-- Author: Jen -->



<!-- Date: Thu Jul 13 09:36:47 2006 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-9076&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-9076  width='300' align='top'></a></td><td>Hmmm... the behavior of f421 has been a bit funny since shutdown.  The bias current had decreased significantly after coming out of shutdown, but since then it's had a really steep increase.  For now I'm going to bump up the limit, and put an entry in the PDB to observe this ladder in a week or two and see if the current increase is continuing at the same rate.</td></tr></table>
<!-- Author: Jen -->

<!-- Date: Thu Jul 13 09:40:47 2006 -->
Entered in Silicon database: <ul>
<li>Ladder: IB4W2L1 
<li>problem n: 1691 
<li>Status: needs_observation
<li>Type: BIAS
<li>Action: IMON_limits
<li>entered by: jpursley 
<li>description is: The bias current of this ladder went pink so I plotted the current history (see <a href= 'http://www-cdfonline.fnal.gov/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=309&frame=2&anchor=09:36:47'>plot</a>).  It's had some funny behavior since shutdown; check the current history again in a week or two and see if this steep current trend is continuing.<table border=1>
<tr><th>IMON LIMITS</th><th>Old</th><th>New</th></tr>
<tr><td><b>Nominal</b></td><td>83</td><td>83</td></tr>
<tr><td><b>Lower</b></td><td>0.5</td><td>0.5</td></tr>
<tr><td><b>Upper</b></td><td>110</td><td>115</td></tr></table> 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=ISL&wedge=B4W2&layer=L1">report</a></ul>
<!-- Author: Problem DB -->



<!-- Date: Thu Jul 13 09:47:44 2006 -->
<h4>No D0 acces today</h4> 
 
<p>D0 don't need their 2 shift access today.  If it ever reappears, we have a plan in place which we can follow.</p>
<!-- Author: Ankush -->



<!-- Date: Thu Jul 13 10:10:14 2006 -->
<h3>BLMs in ACNET: a clarification</h3> 
Just a clarification for everybody: The MADC does not take the raw BLM signal (which is a current, anyway) but the <em>output</em> of the pre-amplifier. Andy pointed out that all four outputs should be hooked up to the MADC. Currently, only two of them are, but the MADC inputs for the other ones are free. So I will hook up all of them after this store. I have also checked on ACNET page D43 that they are in the circular buffers for the lumberjack plotter (both CDF 1 Hz and Tev 1 minute). The corresponding ACNET variables are T:B0LMA1/2 and T:B0LMB1/2.
<!-- Author: Ulrich -->
<!-- Comment: Thu Jul 13 14;53;31 comment by...Ulrich -->
The four channels are now hooked up the MADC. MCR is informed and has added the channels to their monitoring:
<pre>
14:44:37-   CDF people have taken their raw SVX beam abort signals and run them directly to a C290 in Tevatron crate $DB slot 5. The new parameters are: T:B0LMA1, T:B0LMA2, T:B0LMB1, T:B0LMB2 and Todd Johnson has added them to the snapshot manager. - marty
</pre>

<!-- Comment: Thu Jul 13 15;41;01 comment by...Ulrich -->
The people from AD controls (?) who are in charge of maintaining our CAMAC modules have been seen in our control room this afternoon. They vacuum-cleaned the crates and reminded themselves how to replace a C335/6 module in case they have to. The problem is to pull out the card without destroying the piggy-back card on the backside. 
<!-- Date: Thu Jul 13 10:17:16 2006 -->
Entered in Silicon database: <ul>
<li>Ladder: IB0W2L1 
<li>problem n: 1672 
<li>Status: fixed
<li>Type: DVDD
<li>Action: Monitoring
<li>entered by: alscott 
<li>description is: ADCmon dists still look good. 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=ISL&wedge=B0W2&layer=L1">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Thu Jul 13 10:19:22 2006 -->
Entered in Silicon database: <ul>
<li>Ladder: IB4W0L0 
<li>problem n: 1673 
<li>Status: fixed
<li>Type: DVDD
<li>Action: Monitoring
<li>entered by: alscott 
<li>description is: ADCmon dists still look good. 
<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: Thu Jul 13 10:19:22 2006 -->
Entered in Silicon database: <ul>
<li>Ladder: IB4W0L0 
<li>problem n: 1673 
<li>Status: fixed
<li>Type: DVDD
<li>Action: Monitoring
<li>entered by: alscott 
<li>description is: ADCmon dists still look good. 
<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: Thu Jul 13 10:24:15 2006 -->
Entered in Silicon database: <ul>
<li>Ladder: IB5W1L4 
<li>problem n: 1676 
<li>Status: fixed
<li>Type: DVDD
<li>Action: Monitoring
<li>entered by: alscott 
<li>description is: ADCmon dists still look good. 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=ISL&wedge=B5W1&layer=L4">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Thu Jul 13 10:28:47 2006 -->
Entered in Silicon database: <ul>
<li>Ladder: IB0W0L0 
<li>problem n: 1671 
<li>Status: fixed
<li>Type: AVDD
<li>Action: Monitoring
<li>entered by: alscott 
<li>description is: ADCmon dists look good. 
<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: Thu Jul 13 10:32:55 2006 -->
Entered in Silicon database: <ul>
<li>Ladder: IB5W0L0 
<li>problem n: 1331 
<li>Status: fixed
<li>Type: AVDD
<li>Action: Monitoring
<li>entered by: alscott 
<li>description is: ADCmon dists look same as reference. 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=ISL&wedge=B5W0&layer=L0">report</a></ul>
<!-- Author: Problem DB -->



<!-- Date: Thu Jul 13 10:36:13 2006 -->
<center><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-9077&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-9077' width='300'></a></center>
<!-- Author: Adam Scott -->
<!-- Comment: Thu Jul 13 10;42;59 comment by...Adam Scott -->
<pre>This is the ADC distribution for IB5W0L0 (aka f500) on chip 11 (aka chip a1) in run 219659.  The plot looks the same in the reference run (run 185848).  Apparently there is a low bit error (probably bit 0).  However, neither the DS Error Monitor or the BitReporter find this error.

All other chips look good.</pre>

<!-- Comment: Thu Jul 13 12;21;09 comment by...stuart -->
<pre>This makes it seem that the problem is with the data only, rather than a bit error. That could either be due to a problem in the chip or the FIB's processing of the data on the way out. </pre>
<!-- Date: Thu Jul 13 10:46:30 2006 -->
Entered in Silicon database: <ul>
<li>Ladder: IB5W0L0 
<li>problem n: 186 
<li>Status: needs_work
<li>Type: Chip_bit_error
<li>Action: Monitoring
<li>entered by: alscott 
<li>description is: Bit error seen, probably on bit 0 (difficult to see the data because DS EM doesn't find the bit error, so doesn't automatically give the raw data).  See plot in <a href= 'http://www-cdfonline.fnal.gov/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=309&frame=2&anchor=10:36:13'> elog</a>. 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=ISL&wedge=B5W0&layer=L0">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Thu Jul 13 10:48:18 2006 -->
Entered in Silicon database: <ul>
<li>Ladder: IB5W0L3 
<li>problem n: 1674 
<li>Status: fixed
<li>Type: AVDD
<li>Action: Monitoring
<li>entered by: alscott 
<li>description is: ADCmon dists look good. 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=ISL&wedge=B5W0&layer=L3">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Thu Jul 13 10:50:22 2006 -->
Entered in Silicon database: <ul>
<li>Ladder: IB5W1L3 
<li>problem n: 1680 
<li>Status: fixed
<li>Type: AVDD
<li>Action: Monitoring
<li>entered by: alscott 
<li>description is: ADCmon dists look good. 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=ISL&wedge=B5W1&layer=L3">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Thu Jul 13 10:53:30 2006 -->
Entered in Silicon database: <ul>
<li>Ladder: SB2W9L2 
<li>problem n: 1685 
<li>Status: fixed
<li>Type: AVDD
<li>Action: Monitoring
<li>entered by: alscott 
<li>description is: ADCmon dists look good. 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B2W9&layer=L2">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Thu Jul 13 10:53:30 2006 -->
Entered in Silicon database: <ul>
<li>Ladder: SB2W9L3 
<li>problem n: 1668 
<li>Status: fixed
<li>Type: AVDD
<li>Action: Monitoring
<li>entered by: alscott 
<li>description is: ADCmon dists look good. 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B2W9&layer=L3">report</a></ul>
<!-- Author: Problem DB -->



<!-- Date: Thu Jul 13 11:30:28 2006 -->
<table border=0><td><tr><td bgcolor=#e0e030><h3>Webpage to check SVXMon mode</h3> 
To help debug problems like that seen this morning with SVXMon, I have made a little cgi script that checks whether the current instance of SVXMon is running in physics or cosmics mode.  It also checks whether the current tcl file is of the physics or cosmics type.  The web address is <pre>https://www-cdfonline.fnal.gov/cgi/internal/ops/svxii/check_svxmon_mode</pre> and it can be accessed through the <a href="https://www-cdfonline.fnal.gov/cgi/internal/ops/svxii/check_svxmon_mode">Check SVXMon Running mode</a> link on the main Silicon webpage.</td></tr></td></table>
<!-- Author: Mark -->


<!-- Date: Thu Jul 13 11:52:21 2006 -->
<h3>Store lost again, at B4 vacuum valves</h3> 
Not looking good for the vacuum valves... Silicon looks ok.  ACEs already did coldstart, working on getting the rad data.<br>
<!-- Author: Jen -->
<!-- Comment: Thu Jul 13 12;02;59 comment by...Jen -->
<a href=
'http://www-cdfonline.fnal.gov/cgi/elog/elog.pl?nb=2006&action=view&page=487&frame=2&anchor=11:59:10.115'>Fifo plot</a> -- abort was clean for silicon.


<!-- Date: Thu Jul 13 12:08:38 2006 -->
<center><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-9078&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-9078' width='300'></a><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-9079&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-9079' width='300'></a></center>
<!-- Author: Jen -->
<!-- Comment: Thu Jul 13 12;12;59 comment by...Jen -->
Checking out one of our persistent pinkies, e554 AVDD.  The AVDD current has been holding steady for the past week at a lower value than before shutdown.  It doesn't look like the current variation has increased, the current nominal has just dropped.  And it's closer to a value that it used to have, way back when.  The AVDD voltage looks rock solid, so I'm inclined to view this as just a drop in the nominal.  ADCMon plots for recent stores look good too, the ladder is seeing data.  I'm going to change the limits in IMON.

<!-- Date: Thu Jul 13 12:16:39 2006 -->
Entered in Silicon database: <ul>
<li>Ladder: SB5W5L4 
<li>problem n: 1623 
<li>Status: needs_observation
<li>Type: AVDD
<li>Action: IMON_limits
<li>entered by: jpursley 
<li>description is: Lowering IMON limits as the current has been stable for the past week.<table border=1>
<tr><th>IMON LIMITS</th><th>Old</th><th>New</th></tr>
<tr><td><b>Nominal</b></td><td>1120</td><td>1030</td></tr>
<tr><td><b>Lower</b></td><td>1100</td><td>1010</td></tr>
<tr><td><b>Upper</b></td><td>1135</td><td>1050</td></tr></table> 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B5W5&layer=L4">report</a></ul>
<!-- Author: Problem DB -->








<!-- Date: Thu Jul 13 18:06:32 2006 -->
<center><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-9080&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-9080' width='300'></a></center>
<!-- Author: Ankush -->
<!-- Comment: Thu Jul 13 18;12;34 comment by...Ankush -->
<h3>Quartus II now on ncdf205 :-)</h3>

<p>The Quartus II software allows one to spy on the CCC's FPGA and see what it's thinking.  However the software requires a licence.  Peter Wilson told me to mail a chap in the high-rise.</p>

<p>The result: We have a full blown Quartus II and lot of other goodies on the LA PC :-)....so we can probably do a lot more than just spy on the CCC FPGA :-)</p>


<!-- Date: Thu Jul 13 18:19:51 2006 -->
<table border=0><td><tr><td bgcolor=#e0e030>I will be out of town from Friday-Monday afternoon, so if there are any DAQ problems please contact Ankush and he will either take care of it or call in the cavalry.</td></tr></td></table>
<!-- Author: Mark -->


<!-- Date: Fri Jul 14 04:17:52 2006 -->
<b>A moment of philosophizing while waiting on pbars</b><br> 
So I've noticed a couple times this week where the main pager and the SPL have both gotten paged, when really only the main pager should have been.  And the reason seems to be that if the main pager doesn't respond within, say, 30 seconds of the page being sent, the scico assumes the page didn't go through and pages SPL.  Now, I understand that the pager does sometime drop pages.  And I understand that it is important to get someone's response as quickly as possible.  But come on!  It ususally takes AT LEAST one minute for a page to go OUT to the LRP, so responding on a timescale faster than that is just not possible!  The situation as it is now results in two people being woken up in the middle of the night when just one would suffice.<br> 
My point is, if we give them our cell phone number on the white board, shouldn't they try calling that before paging the SPL, if they're concerned about no response?  And really, if it's something urgent, maybe they should just call the cell phone anyway, it's faster than the LRP.  Or maybe we should just remind the scicos of the time involved in the LRP, especially for something non-time-urgent like loading pbars...<br> 
Ok, that was just my little soapbox rant for the night... sorry you got woken up for this shot setup Ankush... pbars are now loaded :)<br>
<!-- Author: Jen -->


<!-- Date: Fri Jul 14 04:27:03 2006 -->
<center><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-9081&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-9081' width='300'></a><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-9082&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-9082' width='300'></a><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-9083&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-9083' width='300'></a></center>
<!-- Author: Jen -->
<!-- Comment: Fri Jul 14 04;34;28 comment by...Jen -->
<b>Checking on our pinkies...</b><br>
So this is another one that's been ignored all week, AVDD for e502.  This one concerns me more b/c the current has such large variations, and has had for a while.  Just last week the limits were bumped up to 845-895 from 800-850.  At least the voltage has stayed steady; that makes this unlike the power-supply-DVDD-oscillation that we replaced at the beginning of shutdown.<br>
In fact, looking at the recent trend of the last few days, the variation has started to settle down quite a bit, at least it's not going nearly as high as it was before and is instead going a little lower.  For the last 3 hrs on the IMON plot, it's held steady at 835.  I'm gonna go ahead and put the limits back down to what they were before, and we'll see what happens.  Maybe it just needed some time after shutdown to adjust itself.<br>

<!-- Date: Fri Jul 14 04:36:21 2006 -->
Entered in Silicon database: <ul>
<li>Ladder: SB5W0L2 
<li>problem n: 1686 
<li>Status: needs_observation
<li>Type: AVDD
<li>Action: IMON_limits
<li>entered by: jpursley 
<li>description is: Current has stayed within the previous limits for the last week, so I'm changing the limits to what they were before.<table border=1>
<tr><th>IMON LIMITS</th><th>Old</th><th>New</th></tr>
<tr><td><b>Nominal</b></td><td>870</td><td>835</td></tr>
<tr><td><b>Lower</b></td><td>845</td><td>800</td></tr>
<tr><td><b>Upper</b></td><td>895</td><td>850</td></tr></table> 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B5W0&layer=L2">report</a></ul>
<!-- Author: Problem DB -->



<!-- Date: Fri Jul 14 04:53:41 2006 -->
<h3>Store 4828 is in...</h3> 
initial lumi ~93 around 4:40am, but once again we're waiting on EVB errors.  This time they happened on Activate instead of Partition, so the the chips have been configed.  However, I seem the same three pinkies that Alice saw <a href= 
'http://www-cdfonline.fnal.gov/cgi/elog/elog.pl?nb=2006&action=view&page=486&frame=2&anchor=01:04:05.562'>last night</a>.  I'll put plots below.  The behavior is the same for all -- when turned on, they excursion just a little bit above the upper limit and immediately come back down, so as soon as you unmark them they're green.  I think I'll bump the current limit up by 5 on each of them... it's kind of a nuisance and could unnecessarily worry an ace.<br>
<!-- Author: Jen -->


<!-- Date: Fri Jul 14 04:56:30 2006 -->
<center><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-9084&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-9085' ></a><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-9086&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-9087' ></a><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-9088&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-9089' ></a></center>
<!-- Author: Jen -->
<!-- Comment: Fri Jul 14 05;00;20 comment by...Jen -->
Bumped e382 bias limit up to 110, e502 bias limit up to 105, and e564 bias limit up to 110.


<!-- Date: Fri Jul 14 05:04:49 2006 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-9090&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-9091  width='300' align='top'></a></td><td>Here's the SVTSpymon plot, now that we're running.  I also checked SVXMon, everything looks good!</td></tr></table>
<!-- Author: Jen -->



<!-- Date: Fri Jul 14 09:01:30 2006 -->
For reference <a href='  
http://www-cdf.fnal.gov/~cschrupp/internal/diamond_plots'>  
 here </a> is the link to the buffer information for the diamonds and new BLM system. We will keep adding new plots as they are available.  
<!-- Author: Ricardo -->


<!-- Date: Fri Jul 14 09:02:00 2006 -->
<table border=0><td><tr><td bgcolor=#e0e030>The iFix tag IA-CONDUCT for the coolant conductivity of the SVX chiller is currently ignored, because the value reached the upper warning limit of 4.0. I will ask for a resin exchange early next week.</td></tr></td></table>
<!-- Author: Ulrich -->


<!-- Date: Fri Jul 14 09:40:13 2006 -->
<center><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-9092&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-9093' ></a><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-9096&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-9096' width='300'></a></center>
<!-- Author: Jen & Satyajit -->
<!-- Comment: Fri Jul 14 09;43;14 comment by...Jen & Satyajit -->
We were going through IMON and checking all the yellows when we found this ladder.  This is one that we swapped out the power supply for at the beginning of shutdown.  Before shutdown, with the old supply, it had ~5 microA of current.  Since shutdown, with the new supply, it has seen 0 current.<br>
We checked the strip plots, and indeed the ladder is seeing data, so it looks fully biased.  It may just be that the current is so small that it appears 0 on the new supply.  If that's the case, the supply should start seeing current again eventually, as radiation damage increases the current.  It's also possible this is another ISL supply monitoring failure, but this supply tested out fine on the teststand (saw current on every bias line).  Time will tell; in the meantime, I'll add this to the PDB as a known 0 current for now.<br>

<!-- Comment: Fri Jul 14 11;07;05 comment by...Jen -->
Forgot to mention: this is f411, Bias1.
<!-- Date: Fri Jul 14 09:46:20 2006 -->
Entered in Silicon database: <ul>
<li>Ladder: IB4W1L1 
<li>problem n: 1692 
<li>Status: needs_observation
<li>Type: BIAS
<li>Action: Diagnosis
<li>entered by: jpursley 
<li>description is: The supply for this wedge was swapped during the 2006 shutdown.  Since then, the BIAS1 current has been 0.  It was only ~5 microAmps at the time of shutdown, so it's possible the current is just too small for the new supply to measure.  If that's the case, this ladder should eventually show current again as the current increases with radiation damage.  In the meantime, this is a known feature of this ladder.  See <a href= 'http://www-cdfonline.fnal.gov/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=309&frame=2&anchor=09:40:13'>plots</a>.    
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=ISL&wedge=B4W1&layer=L1">report</a></ul>
<!-- Author: Problem DB -->



<!-- Date: Fri Jul 14 09:46:57 2006 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-9098&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-9098  width='300' align='top'></a></td><td><h3>A long L1 burst</h3> 
 
<p>The Jet5 trigger went bursty again which fired the GhostBuster.  This one lastyed fora while and even appeared in the 2GAP+JET5 L1A plots.</p></td></tr></table>
<!-- Author: Ankush  -->
<!-- Comment: Fri Jul 14 10;20;59 comment by...Ankush -->
<p>JDL posted a plot of the 2GAP+JET5 rate during this burst.  You can see the L1 rate shoot up.  The plot is in the 
<a href=
'http://www-cdfonline.fnal.gov/cgi/elog/elog.pl?nb=2006&action=view&page=489&frame=2&anchor=07:19:49.630'>
CDF shift e-log</a>.<p>



<!-- Date: Fri Jul 14 09:54:50 2006 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-9099&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-9099  width='300' align='top'></a></td><td>The bias current of f421 has been yellow for the last few days, it's a little bit above the limit.  I plotted the current history, and it dipped down after shutdown and is now on a steep rise.  Hopefully it'll start stabilizing now.  I'm bumping up the current limit and make a PDB entry to observe this in a week and make sure the current increase has slowed down.</td></tr></table>
<!-- Author: Jen & Satyajit -->
<!-- Comment: Fri Jul 14 09;58;30 comment by...Jen -->
Ha! Sleep deprivation strikes again... I thought this current history looks familiar.  Looks like I made the same plot for Bias0 just yesterday (<a href=
'http://www-cdfonline.fnal.gov/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=309&frame=2&anchor=09:36:47'>plot</a>) and the one above is for Bias1.  Good... they should have the same behavior.  Hopefully they'll both stabilize soon.

<!-- Date: Fri Jul 14 10:08:56 2006 -->
<p><font size=+1> D-mode Calibration Job Started </font>
<p><pre>
Job id            : 442
Calibration type  : standard
Run period tag    : Jul_2006
DPS-off run       : 219881
DPS-on run        : 219882
Requested by      : Ed
Main process id   : 20602
</pre>
<!-- Author: CDF silicon D-mode calibration job server v1.4 -->




<!-- Date: Fri Jul 14 10:55:11 2006 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-9100&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-9100  width='300' align='top'></a></td><td>these are the BLM diamonds after the access. The exchanged diamond has a huge gain! do we have gain drops across the digitizers ?</td></tr></table>
<!-- Author: rainer -->


<!-- Date: Fri Jul 14 11:05:20 2006 -->
<br>I started looking at some yellows in IMON, and redefined all those related to our musical ISL power supply swaps during shutdown.  The wedges that got new supplies were: 
<ul> 
<li> IB0W0 
<li> IB4W0 
<li> IB4W1 
<li> IB4W3 
<li> IB5W0 
<li> IB5W1 
<li> IB5W3 
</ul> 
 
All channels for these wedges should be green in IMON (except for f411 Bias1,which I described above).<br>
<!-- Author: Jen -->



<!-- Date: Fri Jul 14 11:10:08 2006 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-9101&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-9102  width='300' align='top'></a></td><td>The current for e1b3 dropped to 0 sometime yesterday without anyone noticing (previously it was about 30 microAmps).  This morning's ADCMon plots look fine, so it's either a readback error or a power supply calibration failure.  During the next quiet time we should try hockerizing this crate.</td></tr></table>
<!-- Author: Jen -->


<!-- Date: Fri Jul 14 12:25:09 2006 -->
<h3>New trigger table to alleviate bursty JET5 trigger</h3> 
 
<p>The L1 bursts which have affected the silicon post-shutdown are known to be a problem with the JET5 trigger.  So a plan was made prescale any trigger using the JET5 trigger.  The changes to the trigger table are: 
 
<ul> 
 
<li>Move 2-gap PS100 from L2 to L1 to help reduce silicon resonances: So the 2GAP+JET5 trigger is presclaed at L1.  If the JET5 goes bursty, it will be reduced by a factor of 100.  That should be fine for silicon.</li>      
 
<li>Drop single-gap triggers: So the GAP EAST/WEST + JET5 are gone.  That was the only other trigger using a unprescaled JET5 trigger.</li>  
 
</ul> 
  
<p>This table was tested today; first a NOSILION and a SILICON run were done.  The test went smoothly and now the new trigger table is the default.  So <em>hopefully</em> we will not suffer form this bursty JET5 trigger.  In addition, more of these events will make it to tape and one can view them on the event display.  Then we can figure out if this is faulty hardware or is really generated by the beam.</p>
<!-- Author: Ankush -->


<!-- Date: Fri Jul 14 14:43:10 2006 -->
<h3>b0fib06 went red</h3> 
The DAQ Ace asked for my help in recovering b0fib06, which went red in RC. He followed the flow chart until the point when he had to shepherd the crate. I gave him permission to take this step as well. Once he had taken the crate through PARTITION, CONFIG, ACTIVATE, HALT, RECOVER, everything was back in the same state again, and data-taking continued.
<!-- Author: Ulrich -->

<!-- Date: Fri Jul 14 14:58:24 2006 -->
<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 442 FAILED.

Job info
--------
Calibration type : standard
DPS-off run      : 219881
DPS-on run       : 219882
Requested by     : Ed
Submitted        : 2006-07-14 10:08:42
Completed        : 2006-07-14 14:58:12
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.499095  

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



<!-- Date: Fri Jul 14 15:48:20 2006 -->
<h3>IMON Barf !!</h3> 
 
<pre> 
Attempting connection to <tcp:b0server05:5101> RTserver. 
Connected to <tcp:b0server05:5101> RTserver. 
Exception in thread "Thread-1" java.lang.OutOfMemoryError: Java heap space 
Exception in thread "Timer-45" java.lang.OutOfMemoryError: Java heap space 
Exception occurred during event dispatching: 
java.lang.InternalError: Unable to Stroke shape (Java heap space) 
        at sun.java2d.pipe.LoopPipe.getStrokeSpans(LoopPipe.java:268) 
        at sun.awt.X11Renderer.draw(X11Renderer.java:343) 
        at sun.java2d.SunGraphics2D.draw(SunGraphics2D.java:2230) 
        at IMONpackage.TimeGraph.DrawLines(TimeGraph.java:445) 
        at IMONpackage.TimeGraph.DrawShapes(TimeGraph.java:220) 
        at IMONpackage.TimeGraph.paintComponent(TimeGraph.java:193) 
        at javax.swing.JComponent.paint(JComponent.java:1005) 
        at javax.swing.JComponent.paintWithOffscreenBuffer(JComponent.java:4963) 
        at javax.swing.JComponent.paintDoubleBuffered(JComponent.java:4916) 
        at javax.swing.JComponent._paintImmediately(JComponent.java:4859) 
        at javax.swing.JComponent.paintImmediately(JComponent.java:4666) 
        at javax.swing.RepaintManager.paintDirtyRegions(RepaintManager.java:451) 
        at javax.swing.SystemEventQueueUtilities$ComponentWorkRequest.run(SystemEventQueueUtilities.java:114) 
        at java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:209) 
        at java.awt.EventQueue.dispatchEvent(EventQueue.java:461) 
        at java.awt.EventDispatchThread.pumpOneEventForHierarchy(EventDispatchThread.java:242) 
        at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:163) 
        at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:153) 
        at java.awt.Dialog$1.run(Dialog.java:515) 
        at java.awt.Dialog.show(Dialog.java:536) 
        at javax.swing.JOptionPane.showOptionDialog(JOptionPane.java:843) 
        at javax.swing.JOptionPane.showMessageDialog(JOptionPane.java:645) 
        at javax.swing.JOptionPane.showMessageDialog(JOptionPane.java:616) 
        at IMONpackage.TimeGraph.SaveToJPEG(TimeGraph.java:701) 
        at IMONpackage.TimeGraph.SaveToJPEG(TimeGraph.java:645) 
        at IMONpackage.History$2.actionPerformed(History.java:146) 
        at javax.swing.AbstractButton.fireActionPerformed(AbstractButton.java:1849) 
        at javax.swing.AbstractButton$Handler.actionPerformed(AbstractButton.java:2169) 
        at javax.swing.DefaultButtonModel.fireActionPerformed(DefaultButtonModel.java:420) 
        at javax.swing.DefaultButtonModel.setPressed(DefaultButtonModel.java:258) 
        at javax.swing.plaf.basic.BasicButtonListener.mouseReleased(BasicButtonListener.java:234) 
        at java.awt.Component.processMouseEvent(Component.java:5488) 
        at javax.swing.JComponent.processMouseEvent(JComponent.java:3126) 
        at java.awt.Component.processEvent(Component.java:5253) 
        at java.awt.Container.processEvent(Container.java:1966) 
        at java.awt.Component.dispatchEventImpl(Component.java:3955) 
        at java.awt.Container.dispatchEventImpl(Container.java:2024) 
        at java.awt.Component.dispatchEvent(Component.java:3803) 
        at java.awt.LightweightDispatcher.retargetMouseEvent(Container.java:4212) 
        at java.awt.LightweightDispatcher.processMouseEvent(Container.java:3892) 
        at java.awt.LightweightDispatcher.dispatchEvent(Container.java:3822) 
        at java.awt.Container.dispatchEventImpl(Container.java:2010) 
        at java.awt.Window.dispatchEventImpl(Window.java:1774) 
        at java.awt.Component.dispatchEvent(Component.java:3803) 
        at java.awt.EventQueue.dispatchEvent(EventQueue.java:463) 
        at java.awt.EventDispatchThread.pumpOneEventForHierarchy(EventDispatchThread.java:242) 
        at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:163) 
        at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:157) 
        at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:149) 
        at java.awt.EventDispatchThread.run(EventDispatchThread.java:110) 
Exception in thread "Timer-48" java.lang.OutOfMemoryError: Java heap space 
Exception in thread "Timer-102" java.lang.OutOfMemoryError: Java heap space 
Exception in thread "Timer-58" java.lang.OutOfMemoryError: Java heap space 
Exception occurred during event dispatching: 
java.lang.OutOfMemoryError: Java heap space 
Exception in thread "Timer-78" java.lang.OutOfMemoryError: Java heap space 
Exception in thread "Timer-83" java.lang.OutOfMemoryError: Java heap space 
Exception in thread "Timer-82" java.lang.OutOfMemoryError: Java heap space 
Exception in thread "Timer-24" java.lang.OutOfMemoryError: Java heap space 
Exception in thread "Timer-70" java.lang.OutOfMemoryError: Java heap space 
Exception in thread "Timer-61" java.lang.OutOfMemoryError: Java heap space 
Exception occurred during event dispatching: 
java.lang.InternalError: Unable to Stroke shape (Java heap space) 
        at sun.java2d.pipe.LoopPipe.getStrokeSpans(LoopPipe.java:268) 
        at sun.awt.X11Renderer.draw(X11Renderer.java:343) 
        at sun.java2d.SunGraphics2D.draw(SunGraphics2D.java:2230) 
        at IMONpackage.TimeGraph.DrawLines(TimeGraph.java:441) 
        at IMONpackage.TimeGraph.DrawShapes(TimeGraph.java:220) 
        at IMONpackage.TimeGraph.paintComponent(TimeGraph.java:193) 
        at javax.swing.JComponent.paint(JComponent.java:1005) 
        at javax.swing.JComponent.paintWithOffscreenBuffer(JComponent.java:4963) 
        at javax.swing.JComponent.paintDoubleBuffered(JComponent.java:4916) 
        at javax.swing.JComponent._paintImmediately(JComponent.java:4859) 
        at javax.swing.JComponent.paintImmediately(JComponent.java:4666) 
        at javax.swing.RepaintManager.paintDirtyRegions(RepaintManager.java:451) 
        at javax.swing.SystemEventQueueUtilities$ComponentWorkRequest.run(SystemEventQueueUtilities.java:114) 
        at java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:209) 
        at java.awt.EventQueue.dispatchEvent(EventQueue.java:461) 
        at java.awt.EventDispatchThread.pumpOneEventForHierarchy(EventDispatchThread.java:242) 
        at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:163) 
        at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:153) 
        at java.awt.Dialog$1.run(Dialog.java:515) 
        at java.awt.Dialog.show(Dialog.java:536) 
        at javax.swing.JOptionPane.showOptionDialog(JOptionPane.java:843) 
        at javax.swing.JOptionPane.showMessageDialog(JOptionPane.java:645) 
        at javax.swing.JOptionPane.showMessageDialog(JOptionPane.java:616) 
        at IMONpackage.TimeGraph.SaveToJPEG(TimeGraph.java:701) 
        at IMONpackage.TimeGraph.SaveToJPEG(TimeGraph.java:645) 
        at IMONpackage.History$2.actionPerformed(History.java:146) 
        at javax.swing.AbstractButton.fireActionPerformed(AbstractButton.java:1849) 
        at javax.swing.AbstractButton$Handler.actionPerformed(AbstractButton.java:2169) 
        at javax.swing.DefaultButtonModel.fireActionPerformed(DefaultButtonModel.java:420) 
        at javax.swing.DefaultButtonModel.setPressed(DefaultButtonModel.java:258) 
        at javax.swing.plaf.basic.BasicButtonListener.mouseReleased(BasicButtonListener.java:234) 
        at java.awt.Component.processMouseEvent(Component.java:5488) 
        at javax.swing.JComponent.processMouseEvent(JComponent.java:3126) 
        at java.awt.Component.processEvent(Component.java:5253) 
        at java.awt.Container.processEvent(Container.java:1966) 
        at java.awt.Component.dispatchEventImpl(Component.java:3955) 
        at java.awt.Container.dispatchEventImpl(Container.java:2024) 
        at java.awt.Component.dispatchEvent(Component.java:3803) 
        at java.awt.LightweightDispatcher.retargetMouseEvent(Container.java:4212) 
        at java.awt.LightweightDispatcher.processMouseEvent(Container.java:3892) 
        at java.awt.LightweightDispatcher.dispatchEvent(Container.java:3822) 
        at java.awt.Container.dispatchEventImpl(Container.java:2010) 
        at java.awt.Window.dispatchEventImpl(Window.java:1774) 
        at java.awt.Component.dispatchEvent(Component.java:3803) 
        at java.awt.EventQueue.dispatchEvent(EventQueue.java:463) 
        at java.awt.EventDispatchThread.pumpOneEventForHierarchy(EventDispatchThread.java:242) 
        at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:163) 
        at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:157) 
        at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:149) 
        at java.awt.EventDispatchThread.run(EventDispatchThread.java:110) 
Exception occurred during event dispatching: 
java.lang.OutOfMemoryError: Java heap space 
Exception in thread "Timer-15" java.lang.OutOfMemoryError: Java heap space 
Exception in thread "Timer-100" java.lang.OutOfMemoryError: Java heap space 
Exception in thread "Timer-123" java.lang.OutOfMemoryError: Java heap space 
Exception in thread "Timer-46" java.lang.OutOfMemoryError: Java heap space 
Exception in thread "Timer-94" java.lang.OutOfMemoryError: Java heap space 
Exception in thread "Timer-112" java.lang.OutOfMemoryError: Java heap space 
Exception occurred during event dispatching: 
java.lang.OutOfMemoryError: Java heap space 
Exception in thread "Timer-51" java.lang.OutOfMemoryError: Java heap space 
Exception in thread "Timer-44" java.lang.OutOfMemoryError: Java heap space 
Exception occurred during event dispatching: 
java.lang.OutOfMemoryError: Java heap space 
Exception occurred during event dispatching: 
java.lang.OutOfMemoryError: Java heap space 
Exception occurred during event dispatching: 
java.lang.OutOfMemoryError: Java heap space 
Exception occurred during event dispatching: 
java.lang.OutOfMemoryError: Java heap space 
Exception in thread "Timer-39" java.lang.OutOfMemoryError: Java heap space 
</pre> 
  
<!-- Author: Ankush -->
<!-- Comment: Fri Jul 14 16;09;26 comment by...Ankush -->
<p>IMON crashed from running out of memory. A simple restart and it was back to normal.</p>



<!-- Date: Fri Jul 14 22:31:47 2006 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-9103&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-9103  width='300' align='top'></a></td><td> </td></tr></table>
<!-- Author:   -->
<!-- Comment: Fri Jul 14 22;42;46 comment by...Ankush -->
<h3>Resonance after moving the JET5 prescale</h3>

<p>Around 9:30pm this evening, we got a resonance.  This run was using the new trigger table with the 2GAP+JET5 trigger prescaled moved to L1. So I thought our woes over resonance would have gone.</p>

<p>But this trace looks like the others. Suddenly the L1 rate goes bursty with an immediate L2R.  So eventually the GhostBuster fires and the run is halted.</p>

<p>If the 2GAP+JET5 prescale is working correctly at Level 1 , we should be auto-accepting at L2.  So it must be another trigger which allows a fast L2R but makes the L1 rate go high.</p>
<!-- Date: Fri Jul 14 22:35:01 2006 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-9104&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-9104  width='300' align='top'></a></td><td> </td></tr></table>
<!-- Author:   -->
<!-- Comment: Fri Jul 14 22;44;07 comment by...Ankush -->
<h3>Zoomed in version of the LA trace during the resonance.</h3>

<p>Here is the same trace as above but zoomed in about the point where the SRC ERROR is fired.  You can see the L1A rate suddenly go to a high rate.</p>


<!-- Date: Fri Jul 14 23:47:55 2006 -->
<h3>Logic Analyser Setup Again</h3> 
 
<p>As it appears the L1A burst is still with us, I have armed the logic analyser by the TS again.  It will be triggered by the LA near the SRC.  If there is another SRC Error, it will trigger both LA.</p> 
 
<p>I'm not sure if the pods to the SCALAR are still looking at GAP EAST/WEST and JET 5...I'll have to ask Greg about that.  But at least we can confirm the L1A the SRC sees is seen by everyone else in CDF.</p> 
 
<p>Let's what we find.</p>  
<!-- Author: Ankush -->


<!-- Date: Sat Jul 15 11:53:09 2006 -->
<h3>Tevatron abort!</h3> 
Store 4829 started with initial lumi ~140, but the Tevatron aborted JUST as we finished ramping silicon.  No quench, so far MCR has no idea what happened, but they give us at least 1 hr quiet time.  I'm using it to look at e453, which had the bias current shoot WAY up (from 50 to 450) this morning (see <a href= 
'http://www-cdfonline.fnal.gov/cgi/elog/elog.pl?nb=2006&action=view&page=493&frame=2&anchor=10:08:50.191'>plot</a>) 
 
  
<!-- Author: Jen -->
<!-- Comment: Sat Jul 15 11;54;15 comment by...Jen -->
D0 just got approved for 1.5 hr access.  

<!-- Comment: Sat Jul 15 12;17;21 comment by...Jen -->
Aces did coldstart, FIFO plot is <a href=
'http://www-cdfonline.fnal.gov/cgi/elog/elog.pl?nb=2006&action=view&page=493&frame=2&anchor=11:45:45.393'>here</a> and we didn't get any radiation.  Now Jim Morgan says the abort may have been temperature related.


<!-- Comment: Sat Jul 15 14;28;18 comment by...Ulrich -->
That plot does not look right to me. You would expect a jump down in the middle of the plot, at the point when the beam is lost and the collision-induced radiation drops out. Could it be a plot taken shortly after the abort? Did you play the <a href=
'http://www-cdfonline.fnal.gov/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=309&frame=2&anchor=17:41:32'>
trick with restricting the time interval</a> before you plotted it?
<!-- Comment: Sat Jul 15 14;53;19 comment by...Jen -->
Yes, I showed the ace how do to the trick.  I just went and checked the plot again myself.  It looks the same when I plot it.
<!-- Date: Sat Jul 15 12:18:17 2006 -->
<center><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-9105&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-9106' ></a><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-9107&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-9108' ></a></center>
<!-- Author: Jen -->
<!-- Comment: Sat Jul 15 12;21;28 comment by...Jen -->
<h3>One problem solved by hockerization, the other not</h3>
There were 2 SVX ladders with bias problems.  One, e543, had a ~400 microAmp current jump this morning at 7:30am.  I hockerized crate 14 and tried powering it again.  Unfortunately, it shows the same high current.  Ankush is coming in, and we'll look at it in SVXDaq. (plot on the left)<br>
The other current problem was 0 current on e1b3 which had been that way for a couple days, but I just noticed it yesterday.  I hockerized crate 1 and HURRAH!  it worked.  Current is now back around its previous value of 30 microAmps. (plot on right)<br>


<!-- Date: Sat Jul 15 12:43:53 2006 -->
<h3>ISL Temp warning for TE-CCE1-1OUT</h3> 
 
<p>Just noticed a temperature warning for ISL CC E1 OUT. It is now at 19.5C, warning is at 19C and alarm at 20C.</p> 
<!-- Author: Ankush & Jen -->


<!-- Date: Sat Jul 15 12:46:27 2006 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-9109&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-9109  width='300' align='top'></a></td><td><h3>Temperature for CC East 1</h3> 
 
<p>The temperature for CC E1 outlet went up recently.</p></td></tr></table>
<!-- Author: Ankush & Jen -->
<!-- Comment: Sat Jul 15 15;26;51 comment by...Jennifer :-) -->
At a glance, I don't really see too much that could have caused this. This is *not* the blocked line, nor does it seem to we well correlated with alcove temperatures. 
<p>
I searched the e-log for "temperature" over last year to see if we had anything similar last summer when it was toasty outside. The only thing that I could see was SVX-related (and from <a href=
'http://www-cdfonline.fnal.gov/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=305&frame=2&anchor=23:41:59'>
June 16th</a>) with the chiller unable to hold his set point. This is not the problem now, as it's just one outlet temp in ISL.
<p>
The next entry I'll put in will be an attempt to correlate alcove, collision hall, and ISL temperatures. Maybe we'll see something there.

<!-- Comment: Sat Jul 15 16;04;37 comment by...Jennifer -) -->
Ok, so iFix is being retarded, and I cannot seem to plot other variables and have them show up. I'll try a couple more times to produce something intelligent. Until then, I don't see any real correlation between outside temps, collision hall temps, alcove temps, and this CCE1_OUT guy. So: my temporary fix is going to be to leave him alone for today. He seems stable, and should be ok throughout the evening since if it is temperature related, it'll be cooler later. Tomorrow is therefore another story.
<p>
So far it's been in warning, but it's constant and not changing. Two days ago, it seemed like it jumped up closer to the warning (I'll put the plot in). Let's just keep an eye on it for now.
<!-- Date: Sat Jul 15 12:59:37 2006 -->
<br><b>Testing the lockCCC module</b><br> 
<br> 
Running RC we remove the lock of the CCC (the CLK 
error showed up, but the transition to RECOVER did 
not occur - a feature if not running std configuration?) 
and once in RECOVER, we used "lockCCC" to relock the 
CCC to RF. This worked, and after a HRR everything was 
fine.   
<!-- Author: Jen/Sebastian -->


<!-- Date: Sat Jul 15 13:13:45 2006 -->
<center><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-9110&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-9110' width='300'></a><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-9111&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-9111' width='300'></a><a href='/elog/notebooks/silicon/Sat_Jul_15_2006_131329.ps'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-9113' ></a></center>
<!-- Author: Jen & Ankush -->
<!-- Comment: Sat Jul 15 13;18;28 comment by...Jen & Ankush -->
<h3>Pinhole on e453</h3>
Above from left: 
<ul>
<li> SVXMon mean charge for chips 6-9 (the last chip has been chopped) from yesterday, before midnight
<li> SVXMon mean charge for chips 6-9 from this morning; spike is clearly visible in the last 5 mins of data taking (e453 went bad ~ 7:30am)
<li> SVXDaq plots of e453.  Spike is clearly visible
</ul>
So it looks like e453 has developed a pinhole. :(  This ladder is already symmetrically biased (50-50) which gives us not very much room to adjust bias splitting.<br>
<!-- Date: Sat Jul 15 13:17:07 2006 -->
Entered in Silicon database: <ul>
<li>Ladder: SB4W5L3 
<li>problem n: 1693 
<li>Status: needs_observation
<li>Type: pinhole
<li>Action: Diagnosis_update
<li>entered by: amitra 
<li>description is: <p>Around 7:30am, 15 July 2005, the Bias current for this ladder jumped up.  During the quiet time, this ladder was investigated in SVXDAQ and a new pinhole was found on the Z-side of this sensor.</p>  <p>Monitoring group should check the occupancy and ADC distribution for this ladder.  If it looks under-depleated, return to Detector and work on the bias will need to be done.</p> 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B4W5&layer=L3">report</a></ul>
<!-- Author: Problem DB -->




<!-- Date: Sat Jul 15 14:05:51 2006 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-9114&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-9114  width='300' align='top'></a></td><td><h3>Clock traces during CCC testing</h3> 
 
<p>When Sebastian was testing the one line command to reset the CCC, the CCC was switched to internal mode.  This trace shows the clocks on the ISL and SVX SRC. The clocks on the SVX SRC (fed by the CCC) are off by one bunch train.</p></td></tr></table>
<!-- Author: Ankush, Jen & Sebastian -->



<!-- Date: Sat Jul 15 14:54:37 2006 -->
Entered in Silicon database: <ul>
<li>Ladder: SB4W0L2 
<li>problem n: 1694 
<li>Status: needs_work
<li>Type: BXing_error
<li>Action: Monitoring
<li>entered by: amitra 
<li>description is: <p>The SVT people said this ladder was giving them occasionsl problems as this ladder sometimes drops the bunch counter.  However the rate of this error is low.  During quiet time, I tried to reproduce it but it ran fine after 5,000 events.</p> 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B4W0&layer=L2">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Sat Jul 15 14:58:18 2006 -->
Entered in Silicon database: <ul>
<li>Ladder: SB0W1L2 
<li>problem n: 2 
<li>Status: fixed
<li>Type: AVDD2
<li>Action: Change_last_chip
<li>entered by: jpursley 
<li>description is: We chopped the z-side (chips a4-a0) as it kept going in and out.  
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B0W1&layer=L2">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Sat Jul 15 14:58:18 2006 -->
Entered in Silicon database: <ul>
<li>Ladder: SB0W1L2 
<li>problem n: 2 
<li>Status: fixed
<li>Type: AVDD2
<li>Action: Change_last_chip
<li>entered by: jpursley 
<li>description is: We chopped the z-side (chips a4-a0) as it kept going in and out.  
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B0W1&layer=L2">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Sat Jul 15 15:00:23 2006 -->
Entered in Silicon database: <ul>
<li>Ladder: SB0W1L2 
<li>problem n: 1666 
<li>Status: needs_observation
<li>Type: AVDD
<li>Action: IMON_limits
<li>entered by: jpursley 
<li>description is: Change limits after chopping z-side<table border=1>
<tr><th>IMON LIMITS</th><th>Old</th><th>New</th></tr>
<tr><td><b>Nominal</b></td><td>750</td><td>580</td></tr>
<tr><td><b>Lower</b></td><td>690</td><td>520</td></tr>
<tr><td><b>Upper</b></td><td>810</td><td>640</td></tr></table> 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B0W1&layer=L2">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Sat Jul 15 15:02:14 2006 -->
Entered in Silicon database: <ul>
<li>Ladder: SB0W1L2 
<li>problem n: 2 
<li>Status: needs_work
<li>Type: AVDD2
<li>Action: Diagnosis_update
<li>entered by: amitra 
<li>description is: <p>Since coming out of the shutdown, the Z side has been coming and going.  I have been comtemplating whether to chop the Z side or not. I finally bit the bullet and now the Z side has been chopped.</p>  <p>In a month's time, we should revisit this ladder and see if the Z-side is more reliable.</p> 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B0W1&layer=L2">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Sat Jul 15 15:02:14 2006 -->
Entered in Silicon database: <ul>
<li>Ladder: SB5W2L2 
<li>problem n: 383 
<li>Status: needs_work
<li>Type: DVDD
<li>Action: Diagnosis_update
<li>entered by: amitra 
<li>description is: <p>Again tried to power up this ladder and it tripped again on DVDD.  So it still stays out.  We should leave for a month and then try again.</p> 
<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: Sat Jul 15 15:03:16 2006 -->
Entered in Silicon database: <ul>
<li>Ladder: SB4W5L3 
<li>problem n: 1693 
<li>Status: needs_observation
<li>Type: pinhole
<li>Action: IMON_limits
<li>entered by: jpursley 
<li>description is: Change IMON limits to accomodate new pinhole<table border=1>
<tr><th>IMON LIMITS</th><th>Old</th><th>New</th></tr>
<tr><td><b>Nominal</b></td><td>42</td><td>460</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>500</td></tr></table> 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B4W5&layer=L3">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Sat Jul 15 15:06:35 2006 -->
Entered in Silicon database: <ul>
<li>Ladder: SB5W5L4 
<li>problem n: 1623 
<li>Status: needs_work
<li>Type: AVDD
<li>Action: Diagnosis_update
<li>entered by: jpursley 
<li>description is: Naturally, as soon as I say the current is stable at the low value, it shoots back up.  Now back around 1100.  It really looks like a chip coming and going, but we're out of quiet time right now... I put it back to ignore for now. 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B5W5&layer=L4">report</a></ul>
<!-- Author: Problem DB -->



<!-- Date: Sat Jul 15 15:16:03 2006 -->
<h3>Quiet time studies</h3> 
 
<p>We took advantage of the quiet time to do some tests</p> 
 
<p>Sebastian was able to test his one-line command to reset the CCC.  This worked fine.  So there is no need to run the CCC program to clear the errors</p> 
 
<p>Two ladders had abnormal currents: e1b3 went to zero e453 jumped up.  e1b3 was fixed by a hockerisation.  Unforunatly e453 is a real jump and diagnosed as a pinhole.</p> 
 
<p>Then Jen and I did some quiet time studies and did the following: 
 
<ul> 
<li>e403:  SVT boys say this is giving BC errors which gives them problems on occasion.  We see it in the bit-reporter but at a very low level.  I tried to reproduce but it gave zero errors after 5,000 events.</li> 
 
<li>e012: Finally bit the bullet and chopped the Z side of this ladder.  But one should revisit this ladder in a month's time.</li> 
 
<li>e522:  Tried powering this ladder again but it still trips on DVDD.</li> 
 
</ul> 
 
</p>
<!-- Author: Ankush and Jen-->
<!-- Author:  -->
<!-- Comment: Sat Jul 15 15;18;54 comment by...Ankush -->
<p>Ankush and Jen did the quiet time studies.</p>



<!-- Comment: Sat Jul 15 16;05;11 comment by...Ankush -->
<table border=0><td><tr><td bgcolor=#e0e030><b>Also SVXDAQ is very, very, very slow....why, why why ????</b></td></tr></td></table>
<!-- Date: Sat Jul 15 15:54:47 2006 -->
<center><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-9115&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-9115' width='300'></a><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-9116&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-9116' width='300'></a></center>
<!-- Author: Ankush -->
<!-- Comment: Sat Jul 15 15;57;39 comment by...Ankush -->
<h3>Current and Voltage of AVDD for e554</h3>

<p>The current and voltage history for e554 since DS-Day 1800.  The voltage looks constant but you can see e554 is slowly drooping.  Then after the shutdown it drops quite a bit.  It looks like a chips is dropping out.  Need to double check this.</p>




<!-- Comment: Sat Jul 15 16;26;12 comment by...Jen & Ankush -->
We tried running e554 in SVXDaq, but the current is high now, and everything looks good.  We really need to run it when the current is low!  I readjusted the current limits so that the AVDD current is now in the green, and left an entry for the aces to page me if it goes pink again.  I'll ask them to restart SVXMon so I can compare data for current high and current low directly.
<!-- Date: Sat Jul 15 16:13:38 2006 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-9117&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-9117  width='300' align='top'></a></td><td>Here's the pic of the electronic cooling water loops.</td></tr></table>
<!-- Author: Jennifer :-) -->
<!-- Comment: Sat Jul 15 16;16;21 comment by...Jennifer :-) -->
So, from <a href=
'http://www-cdfonline.fnal.gov/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=254&frame=2&anchor=15:59:47'>
last summer</a>, when we had chiller problems, we asked the cryo techs to decrease CV-5, therefore increasing chilled water to us. So, as it gets hot hot hot, let's keep this plan in mind.



<!-- Comment: Sat Jul 15 16;51;12 comment by...Ulrich -->
Yes, that was before Jim Loskot cleaned the strainer in the chilled water loop. We did not see anything similar every since. Jim is going to clean the strainer whenever we wills shut down the cooling to replace the conductivity probe.

<!-- Date: Sat Jul 15 16:26:25 2006 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-9118&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-9118  width='300' align='top'></a></td><td>CCE temps for the past 2 weeks. We're looking in the cryo log to see if anything has changed, since we now see that our CCE1_OUT has been on the rise for quite some time now.</td></tr></table>
<!-- Author: Jennifer :-) & Anky -->
<!-- Comment: Sat Jul 15 16;59;19 comment by...Ulrich -->
The structure of the increase looks strange to me. The first dip on July 3 can be explained by the switch-off due to clock problems. But there are several other (correlated) dips as well. Can they be explained by trips or hockerizations? Or is this a drop-out of the cooling?


<!-- Date: Sat Jul 15 17:21:56 2006 -->
<h4>ISL A/W limits set higher</h4> 
<li>So, my first stage was to go ahead following Ulrich's instruction and try to open the manifold valve for CCE1. I did without tripping ISL, but it didn't seem to do much for the temperature. He still hovered around 19.5. I moved the valve from 75% to 80%, and that's where it'll stay. Couldn't hurt since the pressures didn't change when I made the adjustment.</li> 
<li>Next, since that was relatively unsuccessful, I changed the A/W limits on the trip temps page in iFix. Now, CCE1_OUT and all of his friends (not the blocked cooling lines) are set to warning at 20&deg;C and alarm at 21&deg;C. Temperature &uuml;ber-trip still remains at 22&deg;C, so nothing to worry about there. This will keep iFix happy for the time being as we decide what to do about this ONE line that seems to be misbehaving.</li> 
<p> 
We hope that this is nothing serious, since weird temp fluctuations are usually paired with alcove temperature fluctuations--not the case here. So, now, this particular line is receiving more flow, and maybe over some time it'll come back down. Will email Andy to see if he has some insight.  
<!-- Author: Jennifer :-), Anky and Jen in the control room & a remote Ulrich -->
<!-- Comment: Sat Jul 15 17;44;52 comment by...Ulrich -->
Just a couple of random thoughts from my side:
<ul>
<li> If the pressure did not change while you were opening the valve, you probably could have gone further up. That is still somethiing we can try later. </li>
<li>Also, it is the temperature at the outlet of CCE1 in ISL Layer 6 which is higher. The corresponding inlet temperature is about stable. Did we change anything in the detector around that spot? Is some ladder drawing more current than it used to? Or is there something which blocks the cooling line?</li>
</ul>

<!-- Comment: Sat Jul 15 18;07;56 comment by...Ulrich -->
I did another e-log search, this time on "CCE1". And indeed: an increase in the temperature CCE1L6_1OUT has been reported several times in the last years, mainly back in 2002. It seems that the cooling for this guy is just sufficient. Maybe there are air bubbles in the system? Here are some examples:
<a href=
'http://www-cdfonline.fnal.gov/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=113&frame=2&anchor=21:15:32'>
1</a>,
<a href=
'http://www-cdfonline.fnal.gov/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=114&frame=2&anchor=16:45:38'>
2</a>,
<a href=
'http://www-cdfonline.fnal.gov/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=134&frame=2&anchor=20:16:15'>
3</a>,
<a href=
'http://www-cdfonline.fnal.gov/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=135&frame=2&anchor=20:49:04'>
4</a>,
<a href=
'http://www-cdfonline.fnal.gov/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=137&frame=2&anchor=10:00:15'>
5</a>,
<a href=
'http://www-cdfonline.fnal.gov/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=222&frame=2&anchor=16:33:56'>
6</a>,

<p>
What they tried to do is what I proposed earlier: crank up the flow as far as possible.
Note also that the line is related to IB4W0L1,L3; IB4W4L3; IB4W5L1,3.



<!-- Date: Sat Jul 15 19:10:39 2006 -->
<h3>CCE1 was 20.7</h3> 
Jennifer will be here shortly to try opening the flows even more.  In the meantime, I'm fearful enough of the quick temperature rise that I turned off all three wedges Ulrich mentioned above: IB4W0, IB4W4, and IB4W5.  After doing that, the temperature is droping rapidly, it's already down to 12 degrees.<br>
<!-- Author: Jen -->
<!-- Comment: Sat Jul 15 19;15;06 comment by...Jen -->
Ok, that was making it quite chilly (10 degrees and still dropping) so I just turned IB4W0 back on.  Now it seems to be stabilizing around 14.


<!-- Date: Sat Jul 15 21:32:45 2006 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-9120&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-9120  width='300' align='top'></a></td><td><h3>Progress!</h3> 
Let's look at some of the features in out plots: 
<ul> 
<li>First rise has f401, f403, f451 & f453 all in</li> 
<li>All 4 back out... chilly!</li> 
<li>WE take f451 & f453 out, gives us the plateau starting around 7:15pm</li> 
<li>Back to the large plateau at 8:00pm; be cautious, Jennifer :-) was playing with flows and the temperatures fluctuated a bit before we realized that the COT-face pressure was too high. Woops.</li> 
<li>So, let's then remove only f401 and f403: this is the plateau at approximately 9:00pm</li> 
<li>Finally, we leave f403 out, and stabilize around 17°C.</li></ul> 
Note: we could have also just left f401 out, and probably have achieved the same result. It might not just be f403's fault, but there is definitely something fishie going on!</td></tr></table>
<!-- Author: Jennifer :-), Jen & Ankush -->
<!-- Comment: Sat Jul 15 22;03;01 comment by...Ankush -->
<p>I check the AVDD and DVDD currents for f401 and f403.  There are no big jumps in the current.  So that doesn&#39t explain why they contribute so much heat.</p>

<p>May be these ladders are closest to the RTD for the affected cooling line...can any of the <em>old guys</em> comment.</p>
<!-- Comment: Sat Jul 15 22;08;59 comment by...Ulrich -->
The problem is that there is no obvious single reason for temperature excursion. It could be the ladder dissipating more heat, the cooling system not providing enough flow, bubbles in the cooling line, the increased outside temperature, a sack of rice in China, ...
Let&#039;s hope the additional small heat load from biasing the ladders does not tip over the fragile balance... 
<!-- Comment: Sun Jul 16 00;29;03 comment by...Lady in Pink :-) -->
Please see the <a href=
'http://www-cdfonline.fnal.gov/cgi/elog/elog.pl?nb=2006&action=view&page=494&frame=2&anchor=21:59:07.972'>
main e-log</a> for comments from the "peanut gallery".
<!-- Comment: Mon Jul 17 15;19;09 comment by...Old Guy (Andy H.) -->
Ankush's conjecture is correct --- f451 is closest to the inlet RTD, and f403 is closest to the outlet RTD.

<!-- Date: Sat Jul 15 21:45:51 2006 -->
Entered in Silicon database: <ul>
<li>Ladder: IB4W0L3 
<li>problem n: 1695 
<li>Status: needs_work
<li>Type: Other
<li>Action: Removed_hdwdb
<li>entered by: jpursley 
<li>description is: We had to remove this ladder to keep the temperature (CCE1_OUT) below the alarm limits.  Hopefully we'll be able to put it back in once we figure out the real problem... see <a href= 'http://www-cdfonline.fnal.gov/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=309&frame=2&anchor=21:32:45'>elog</a>. 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=ISL&wedge=B4W0&layer=L3">report</a></ul>
<!-- Author: Problem DB -->






<!-- Date: Sun Jul 16 01:36:56 2006 -->
<h3>Store 4835 is in</h3> 
Initial lumi only ~62, but at least the store has stayed in this far.  However we haven't started datataking due to TOF trip.  The silicon is biased; I've been watching TE-CCE1-1OUT and it went up from 17.8 to 17.9.  So far, so good.  Hopefully we start taking data soon...
<!-- Author: Jen -->


<!-- Date: Sun Jul 16 02:16:44 2006 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-9121&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-9122  width='300' align='top'></a></td><td>Finally running!  SVTspymon looks fine.  SVXMon looks fine.  The temp TE-CCE1-1OUT is staying around 17.8-17.9 degrees.  Everything looks fine!</td></tr></table>
<!-- Author: Jen -->


<!-- Date: Sun Jul 16 08:17:54 2006 -->
<h3>Separator spark</h3> 
From MCR: 
<pre> 
 CDF silicon is off right now. TRF2 burped and AGIGI2 climbed to 35. Steve is scrubbing away at the abort gap right now.  - dln 
</pre> 
 
Shift crew took silicon to standby as soon as they saw the huge spike in losses caused by the separator spark, and called me in when they saw AGIGI2 start decreasing. 
AGIGI2 is down to 4.6 and MCR says they're done with it, so I gave permission to reinclude silicon.  Have to keep an eye on it...<br>
<!-- Author: Jen -->
<!-- Comment: Sun Jul 16 08;33;33 comment by...Jen -->
AGIGI2 started increasing rapidly as soon as the expert left, went up to 5.3. MCR says they're still working it and may need to call the expert back.  In the meantime we're running without silicon.

<!-- Comment: Sun Jul 16 08;42;37 comment by...Jen -->
Ok, they got it down to 3.6 so we're reincluding silicon.

<!-- Comment: Sun Jul 16 10;33;19 comment by...Jen -->
More *&%$ing AGIGI2 problems... shift crew took silicon to standby and asked MCR to clean the gap again.  MCR did so... their claim is that we're not seeing any "new" particles in the gap.  Instead, same old particles are moving around within the gap, and they're only scanning a small piece of the gap, so the amount we see depends on how many particles have moved into their scanning area.  Not very confidence inspiring, since it indicates that their value of AGIGI2 is lower than it should be.  But they <b>think</b> they got it cleaned up sufficiently this time that it should stay below our warning limits.  I'm going to sit in the control room and keep an eye on it.


<!-- Comment: Sun Jul 16 14;00;20 comment by...Jen -->
<pre>Things were stable for a long time around a value of 2 (!), but then all of a sudden it started rising.  I waited until 5.5 before calling this time (it was going up 0.5 every ~40 mins), and MCR is now cleaning the gap for us again.  Silicon at standby until they're done.
</pre>
<!-- Date: Sun Jul 16 12:41:11 2006 -->
<h3>CCE1L6-1OUT cooling problems: more facts and speculations</h3> 
I have had another look at the cooling problem with output temperature of ISL Layer 6 Forward Outer cooling line #1. I have plotted the history of all ISL cooling temperatures since the end of the shutdown. There is a second temperature on the rise, CCE2L6_2OUT (for ISL Layer 6 Forward Central), albeit on a much smaller level. Also CCW2L6_1IN shows a slight detour but seems to be coming back to normal. All others are pretty stable over the last 40 days. Unfortunately, we do not have historic data for more than 99 days before today. I have asked Bill Noe to burn a CD with those data. Also, we do not currently have a stand-alone iFix PC to plot the data (our old licence on the test stand PC was revoked with the iFix 4.0 upgrade, and we have not yet set up a new iFix PC) and I did not want to interfere with the ongoing data-taking. 
<p> 
Ankush was interested in the changes to the cooling since we added glycol to the system in 2005 (step 1: 06/22/05, step 2: 08/04/05). In order to maintain enough flow, we opened the e-valve on CCE1 from 70% to 75% on 08/04/05. 
The temperature gradient from the CCE1L6-1 input to the output was much smaller back then (8.7 &rarr; 12.2&deg;C on 06/22/05, 8.7 &rarr; 11.2&deg;C on 08/04/05) than it is now (7.7 &rarr; 17.9&deg;C). The input temperature is even one degree lower than it was before! Wild speculation by UH: could the fact that the coolant is more viscous at lower temperatures together with the reduced heat capacity of water/glycol mixture as compared to pure water be the cause of our problem? But then: why now?
<!-- Author: Ulrich -->
<!-- Comment: Sun Jul 16 12;43;24 comment by...Ulrich -->
<table border=0><td><tr><td bgcolor=#e0e030>Note to cooling experts: 
<ul>
<li>I found the alarms on both the SVX and ISL chiller compressors ignored in iFix. Why?</li>
<li>The ISL CC trip limit is still at 22&deg;C. We have to bring it back to 21&deg;C eventually.</li>
</ul></td></tr></td></table>


<!-- Comment: Sun Jul 16 14;19;17 comment by...Jennifer :-) -->
YIKES. I did NOT ignore the compressors... the only iFix alarms that Jen and I toggled with yesterday were ISL power supplies as we fiddled with a few ladders. Those were re-included (i.e. ignore alarm set to NO) last night once we were finished.
<p>
I have the documentation on paper, but I forgot yesterday to put my ISL CC trip limit at 22&deg;C documentation in the e-log; sorry about that. I'll put it in now, and YES, let's bring it back down once we are convinced of what was causing the heat load/insufficient cooling. This way, we keep the pages down :-)
<!-- Comment: Sun Jul 16 14;22;00 comment by...Jennifer :-) -->
Woops. Looks like the documentation was there.
<!-- Date: Sun Jul 16 12:47:29 2006 -->
<center><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-9123&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-9123' width='300'></a><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-9124&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-9124' width='300'></a><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-9125&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-9125' width='300'></a></center>
<!-- Author: Ulrich -->
<!-- Comment: Sun Jul 16 12;48;32 comment by...Ulrich -->
History plots for CCE1, CCE2, and CCW2. The time interval is 99 days for CCE1 and 40 days for CCE2 and CCW2.





<!-- Date: Sun Jul 16 16:03:37 2006 -->
<pre>AGIGI2 is still misbehaving.  Every time they clean it, it comes right back, and they don't seem to know why either.  They can't keep it below 5 worth beans, but it's a little bit better staying between 5 and 6.  Right now I'm sitting here monitoring it.  My plan is to call them whenever it starts staying consistently above 6 (which is about to happen soon) and ask them to clean it up. 
</pre>
<!-- Author: Jen -->
<!-- Comment: Sun Jul 16 20;32;02 comment by...Jen -->
<pre>Finally an answer from MCR... they think the AGIGI2 problem is due to a RF Modulator not doing its job.  
After the store is dropped at midnight they're going to take a look at it before putting in the next store.  
Only another 3.5 hrs of suffering to go...</pre>


<!-- Comment: Mon Jul 17 04;17;15 comment by...Jen -->
See <a href=
'http://www-cdfonline.fnal.gov/cgi/elog/elog.pl?nb=2006&action=view&page=497&frame=2&anchor=19:45:04.260'>plot</a> of AGIGI2.
<!-- Date: Sun Jul 16 21:25:21 2006 -->
<h2>Tevatron quenched</h2> 
... at E1.  That's all we know right now.  Aces did coldstart and the FIFO plot is <a href= 
'http://www-cdfonline.fnal.gov/cgi/elog/elog.pl?nb=2006&action=view&page=497&frame=2&anchor=21:20:31.139'>here</a>.  But it looks the same as last time, just straight lines and no sign of the abort.  I tried plotting it with the trick and without the trick, and got the same plot. ???<br> 
On the bright side, AGIGI2 is no longer a problem.  Luckily it was around 5.3 when we quenched, only a little above warning.  Good thing we kept making MCR mind the gap!<br>
<!-- Author: Jen -->
<!-- Comment: Sun Jul 16 22;51;10 comment by...Jennifer :-) -->
It'll be over tomorrow!!!! Hang in there!!!! :-) By the way, you SO deserve a party!


<!-- Comment: Mon Jul 17 04;02;35 comment by...Jen -->
From the run coordinator elog:
<pre>
 The store was lost when the C17V separator either sparked or changed output.
</pre>
<!-- Comment: Mon Jul 17 09;16;20 comment by...rainer -->
<pre>what did the diamonds see ? </pre>
<!-- Date: Sun Jul 16 22:54:46 2006 -->
<h4>SVXiiCON PC rebooted</h4> 
The friendly iFix PC was rebooted yesterday afternoon.
<!-- Author: Jennifer :-) -->




<!-- Date: Mon Jul 17 04:27:14 2006 -->
<h2>CCE1L6-1OUT still rising</h2> 
Just checked it and it's back at 19.2 degrees, even with f403 out.  If it goes much higher, I'll take out another ladder...<br>
<!-- Author: Jen -->
<!-- Comment: Mon Jul 17 04;55;43 comment by...Jen -->
19.3 now that we're biased.  I'll leave it alone for now and tell the ace to call me if ISL goes yellow.
<!-- Date: Mon Jul 17 04:54:27 2006 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-9126&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-9127  width='300' align='top'></a></td><td>Store 4838 is in, initial lumi ~80.  SVTSpymon is good, SVXMon is good.  So far losses look great, and AGIGI2 is stable around 0.8 (woo-hoo!)</td></tr></table>
<!-- Author: Jen -->


<!-- Date: Mon Jul 17 05:16:02 2006 -->
Entered in Silicon database: <ul>
<li>Ladder: SB1W8L2 
<li>problem n: 1696 
<li>Status: needs_observation
<li>Type: Unknown
<li>Action: Monitoring
<li>entered by: yuji 
<li>description is: New bump in ADC distribution of chip[0-4] is observed in run 219946. 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B1W8&layer=L2">report</a></ul>
<!-- Author: Problem DB -->



<!-- Date: Mon Jul 17 08:47:24 2006 -->
<h4>Weekly Summary 7/10 - 7/17</h4> 
<ul> 
<li> Monday 
     <ul> 
     <li> Store 4818 ongoing 
     <li> Clock glitch, BX error 
     <li> f512 began tripping more regularly on AVDD Undervoltage 
     </ul> 
<li> Tuesday 
     <ul> 
     <li> Took f512 out of HWDB due to trips 
     <li> Couple pinkies in IMON: AVDD e012 (losing z side), AVDD e502 (oscillating?) 
     <li> Drop store 09:00, go in for 2 hr access: 
	  <ul> 
	  <li> Diamond work 
	  <li> Fail to replace supply for f512 
	  </ul> 
     <li> Store 4821 at 16:00, initial lumi 163 
     <li> Crate 13 turned off at beginning of store, recovered 
     <li> More pinkies 
     </ul> 
<li> Wednesday 
     <ul>  
     <li> 00:54 -- Rad abort!  Appears to be CDF system malfunction 
     <li> Replace some electronics, setup monitoring... 
     <li> Store 4822 at 08:00, initial lumi 109 
     <li> Store abort on B4 vacuum valves at 12:00, clean for silicon 
     <li> Trick to plotting correct FIFO abort data 
     </ul> 
<li> Thursday 
     <ul> 
     <li> Store 4825 at 00:45, initial lumi 67.  EVB prevented datataking for 1.5 hrs 
     <li> More pinkies: bias lines still adjusting after shutdown 
     <li> Silicon standby 07:00 for an hour as CLC PC reboot fails 
     <li> Discovered SVXMon in cosmics mode (ConCon lied!) 
     <li> Store abort on B4 vacuum valves at 12:00, clean for silicon 
     </ul> 
<li> Friday 
     <ul> 
     <li> Store 4828 at 04:40, initial lumi 93.  More EVB errors. 
     <li> Redefining some yellows & pinkies 
     <li> Another L1 burst, new trigger table in the works 
     <li> b0fib06 unpingable, need soft reboot 
     <li> Took D-mode calibration (status: failed) 
     <li> Tested new trigger table 
     <li> Got L1 burst with new trigger table :( 
     </ul> 
<li> Saturday 
     <ul> 
     <li> Store 4828 terminated normally 08:00 (yippee!) 
     <li> Store 4829 at 11:30, initial lumi 140. Tevatron abort 4 mins after scraping, clean for silicon. 
     <li> Quiet time studies 
	  <ul> 
	  <li> Tested Sebastian's lockCCC code, works 
	  <li> New pinhole on z-side of e453 :( 
	  <li> Chopped z-side of e012 
	  </ul> 
     <li> ISL Temp warning for CCE1L6-1OUT 
     <li> Take f403 out of HWDB to keep CCE1L6-1OUT cool 
     <li> Watching e554, AVDD current high again.  Chip coming and going? 
     </ul> 
<li> Sunday 
     <ul> 
     <li> Store 4835 at 01:30, initial lumi 62.  TOF prevented datataking for 1 hr. 
     <li> Separator spark 07:00, silicon standby until losses recover 
     <li> AGIGI2 periodic rising all through store, ask MCR to clean 
	  abort gap every 2 hrs or so 
     <li> Tevatron quench (E1) at 21:30 due to C17V separator, clean for silicon	   
     </ul> 
<li> Monday 
     <ul> 
     <li> Store 4838 at 04:40, initial lumi 80. 
     </ul> 
<li> <b>Still watching:</b> 
     <ul> 
     <li> CCE1L6-1OUT, CCE2L6_2OUT temperatures still rising 
     <li> Reinclude f403 if CCE1L6-1OUT drops 
     <li> ISL CC trip limit temporarily at 22 C, must be lowered eventually 
     <li> e554, want to catch it with the current low 
     <li> PS for f512 still needs swapped when we get a spare 
     </ul> 
</ul>  
<!-- Author: Jen -->