<!-- Title: 09:44:46  Mon Mar 29 2004 -->
<!-- Crewchief: julia -->
<!-- Op1: and si group -->
<!-- Op2: &nbsp; -->
<!-- Op3: &nbsp; -->
<!-- Op4: &nbsp; -->
<!-- Op5: &nbsp; -->
<!-- Op6: &nbsp; -->
<!-- Notes: -->
<pre>neues spiel, neues glueck</pre>


<!-- Date: Mon Mar 29 10:34:54 2004 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-3691&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-3692  width='300' align='top'></a></td><td>step up in DVDD by 40 mA</td></tr></table>
<!-- Author: julia -->


<!-- Date: Mon Mar 29 11:06:54 2004 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-3693&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-3694  width='300' align='top'></a></td><td>DVDDL4 history</td></tr></table>
<!-- Author: julia -->


<!-- Date: Mon Mar 29 11:08:02 2004 -->
<pre>svx B4W7L4 just came back to normal (~160mA) again.</pre>
<!-- Author: julia -->

 
<!-- Date: Mon Mar 29 11:30:17 2004 -->
<pre>Agreed with Sal on the following L2 w/o L1 A procedure: 
 
-SRC status page: read 
-to TSI: L2 Done will show red and on the errors page we'll see L2 w/o L1A 
-TSI Emulator: click L1A0->L2AO 
-perform HRR 
 
If I get paged while at FNAL, I'll take care of it and call him to check trigger. If I'm at home I'll call him (he can do it from home, I would have to drive to the lab).</pre>
<!-- Author: julia -->


<!-- Date: Mon Mar 29 13:08:34 2004 -->
<pre>DVDD pinkie on sb4W7L4 came back. Redefined upper limit from 170mA to 200mA. no bit errors or other problems seen.</pre>
<!-- Author: julia -->

<!-- Date: Mon Mar 29 13:37:49 2004 -->
Entered in Silicon database: <ul>
<li>Ladder: IB4W3L2 
<li>problem n: 1175 
<li>Status: needs_observation
<li>Type: AVDD
<li>Action: IMON_limits
<li>entered by: thom 
<li>description is: jump back to 1177<table border=1>
<tr><th>IMON LIMITS</th><th>Old</th><th>New</th></tr>
<tr><td><b>Nominal</b></td><td>1085</td><td>1180</td></tr>
<tr><td><b>Lower</b></td><td>1075</td><td>1160</td></tr>
<tr><td><b>Upper</b></td><td>1190</td><td>1095</td></tr></table> 
<li>See <a href="http://www-cdfonline.fnal.gov/internal/usr/lmiller/cgi-bin/newproblemdb/DBreport.pl?detsys=ISL&wedge=B4W3&layer=L2">report</a></ul>
<!-- Author: Problem DB -->
<!-- Comment: Mon Mar 29 13;47;59 comment by...julia -->
<pre>Current has oscillated frequently in the past (between 1175 and 1075mA).</pre>


<!-- Date: Mon Mar 29 15:41:17 2004 -->
<pre>abort gap losses larger than 20 kHz, TevMon alarm and Si to STBY.  
MCR is tuning.</pre>
<!-- Author: julia -->
<!-- Comment: Mon Mar 29 15;41;58 comment by...julia -->
<pre>..they're calling back when done</pre>


<!-- Date: Mon Mar 29 15:52:38 2004 -->
<pre>MCI is done and the AGLosses look stable at 12kHz. Si back to ON.</pre>
<!-- Author: Julia -->


<!-- Date: Mon Mar 29 18:14:32 2004 -->
<center><a href='/elog/notebooks/silicon/Mon_Mar_29_2004_180932.ps'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-3696' ></a><a href='/elog/notebooks/silicon/Mon_Mar_29_2004_180951.ps'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-3698' ></a><a href='/elog/notebooks/silicon/Mon_Mar_29_2004_181346.ps'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-3700' ></a><a href='/elog/notebooks/silicon/Mon_Mar_29_2004_181353.ps'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-3702' ></a></center>
<!-- Author: SCN,Reid,Julia,Marcel -->
<!-- Comment: Mon Mar 29 18;29;20 comment by...SCN,Reid,Julia, Marcel -->
<h3> Ghostbuster testing ...</h3>

After changing the cables to literally golden ones, the situation really improved, the cables obvioulsy made a difference.<br>
The situation today is the following:<br>

<b>ch0</b> has always worked nicely (first plot) <br>
<b>ch1</b> is now working, but the SRC does not pull any error , as you can the GBOUT signal as seen on the mezzaine card is inverted .After the previous experiences, this may be again a cabeling issue. (second plot) <br>
<b>ch2</b>  is working nicely and always has the brake2 is of no use, as Taka changed this for some debugging (third plot)<br>
<b>ch3</b>  is now working nicely  besides brake, which is now a clock (debugging again ...) (fourth plot)<br>
So right now, three of four channels are working fine

For the plots, here is a little legend
<pre>
FL1A L1 Accept
GBIN  Ghostbuster Input on the mezzaine card ( same as FL1A)
CABLIN Ghostbuster Input on the Ghostbuster ( same as FL1A)
BRAKE the brake send by the ghostbuster
GBOUT Ghostbuster Output on the mezzaine card (same as brake)
CNT0/1 The kick counters 
</pre>

We'll investigate the ch1 problem ...


<!-- Date: Mon Mar 29 20:01:33 2004 -->
<pre>beam lost. Don't know why yet. Silicon in STBY.</pre>
<!-- Author: julia -->
<!-- Comment: Mon Mar 29 20;08;22 comment by...julia -->
<pre>beam aborted because quad tripped. aces did the post-quench check-out.</pre>


<!-- Date: Mon Mar 29 21:42:07 2004 -->
<h3> <font color="red">Red Handed!</font></h3> 
I found the SRC in error, doing nothing, with L2 w/o L1A. It seems that there is a lone L2A sitting in the middle of nowhere. 
<br><br> 
The fib commands sent previous to this were: 
40,64,40,42,62 
<br><br> 
I will paste the scope trace in a moment.
<!-- Author: Sal -->
<!-- Comment: Mon Mar 29 21;55;33 comment by...Sal -->
Other command chains previous to L2R:
<pre>
40,64,40,62,40
40,64,40,62,40
40,64,40,62,40
</pre>
It seems that there was a spurious L2R (0x42) in Dear Fib.
It seems to be a glitch (it is enabled for only 22 ns).


<!-- Date: Mon Mar 29 22:02:58 2004 -->
<center><a href='/elog/notebooks/silicon/Mon_Mar_29_2004_220233.ps'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-3704' ></a><a href='/elog/notebooks/silicon/Mon_Mar_29_2004_220244.ps'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-3706' ></a></center>
<!-- Author: Sal -->
<!-- Comment: Mon Mar 29 22;05;56 comment by...Sal -->
Here are the plots. On the left, you see the L2 decision
(actually L2R). On the right, you see the Dear Fib commands
immediately prior to the L2R. Indeed, there is a spurious 0x42 that
is very short lived (22 ns).


<!-- Date: Tue Mar 30 09:33:51 2004 -->
<center><a href='/elog/notebooks/silicon/Tue_Mar_30_2004_093149.ps'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-3708' ></a><a href='/elog/notebooks/silicon/Tue_Mar_30_2004_093243.ps'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-3710' ></a><a href='/elog/notebooks/silicon/Tue_Mar_30_2004_093329.ps'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-3712' ></a></center>
<!-- Author: SCN -->
<!-- Comment: Tue Mar 30 10;17;49 comment by...SCN -->
<h3>A closer look</h3>
The trigger occured at 21:32:08.  The three pictures above are <ul>
<li> Left: Close up of L2A, which is ~ 132 ns, so it is a healthy L2A.  There is no other signals (TAXI, L1A, L1D, L2R ...) around this bare naked L2A. 
<li> Center: The PREAMP reset approximately 3.8 &mu;s before the
errant L2A.  Some comments regarding the 0x42 signal <ol>
<li> It is <= 20 ns wide, which is the bin width of the LA
<li> It does not coincide with any CDF Clock, so it was not
sent down to the FIBs or anything
<li> 0x42 is just a non-execute immediate PARST STOP (like 0x62 without bit 6, which is execute immediate) and has nothing to do with L2A at all
</ol>
Given these, I think the LA just sampled the dearFib lines while they were in transition and no more time should be spent on it
<li> Right: About 785 &mu;s AFTER the error, the code 0x20 appeared on the TAXI line.  I checked that we were in TAXI LA setup 2, and since that was true this means the TS sent a L1A word with
GLIVE set high, for several microseconds.  No other TAXI commands 
appeared in the 20 ms trace of the LA.  It is possible something
was about to be sent, and the errant L2A has to do with the CONFIG transition or something.
</ul>
I searched the LA time window for other TAXI commands, L1As, READBUSY, or any FIB command without the ADVANCE PIPE bit (bit 5)
and didn't find anything.  I did find the KEEPALIVEs continued
throughout the entire trace at ~ 270 &mu;s intervals which is expected.  <P>
I then set the LA on the fancy trigger, which looks for (SRC1 pulls ERR or SRC2 pulls ERR) and then that the ESTRING bit stays low for 400 nS, so that we don't catch Estring errors.  I tested
it by sending a naked L2A with svxdaq, and it works fine.  I think someone might want to look at the last partition the SRC was in (presumably for the post quench cheeckout) and see what happened in that partition around 21:32:08, if anything.  In principle, after any ABORT or END of run, the SRCs trigger interface is turned to OFF, so it shouldn't matter.<P>
If nothing looks obvious there, then we just have to understand
why the SRC would produce a spurious L2A out of nowhere...


<!-- Date: Tue Mar 30 12:12:50 2004 -->
<pre>store 3335 went in. Problem: LOSTP is rising (around 22kHz now). MCR starting program of standard vertical tuning, so I'm leaving the silicon in. If they're planning anything more drastic they'll call me.</pre>
<!-- Author: julia -->


<!-- Date: Tue Mar 30 12:22:18 2004 -->
<pre>LOSTP is over 25kHz for 3 mins now, very spikey and moving around too much. Si in STBY.</pre>
<!-- Author: julia -->


<!-- Date: Tue Mar 30 12:44:52 2004 -->
<h3><font color="red">ARRRGGHH!!! $*#$ Scope didn't fire!</font></h3> 
RC got an "L2 w/o L1" error from the SRC on END (which would have shed a WHOLE lot of light on this situation), but the scope did not fire. 
Firstly, the "brake" line was set to the wrong thing, but it should have fired anyway. As the shift crew is waiting to take data, 
I cleared the error and gave them the go-ahead.
<!-- Author: Sal R. -->
<!-- Comment: Tue Mar 30 12;53;16 comment by...Sal -->
Check that, I understand what happened. The scope trigger was:
<ol>
<li> Edge1 OR Edge2 (Edge1 = SERR2, Edge2 = SERR1), goto 2
<li> Wait 400 ns, if you see "E", goto 1 (E = XX), else trigger
</ol>
<br>
"E" was not set, so every time you get Edge1 OR Edge2, the
trigger would return to Level 1. What we wanted was "C",
which was "BRAKE".
<br>
<br>
C`est la vie. We would have learned a lot from this guy.
<!-- Date: Tue Mar 30 12:48:24 2004 -->
<pre>MCR is starting re-scraping</pre>
<!-- Author: julia -->



<!-- Date: Tue Mar 30 13:34:30 2004 -->
<pre>re-scraping done, LOSTP better now, at 13kHz and less spikey. Si to ON</pre>
<!-- Author: julia -->


<!-- Date: Tue Mar 30 14:44:30 2004 -->
<h3>SRC Errors (Again)</h3> 
The PCAL crates are giving me a headache. The aces have reset the VRB for PCAL in b0evb16, slot 10 (PCAL 11, I think). The SRC 
was thrown into error a few times. I did catch this one at 
the first instance and have saved the configuration. Unfortunately, we do not have the TSI Emulator LA ports hooked up at the moment, so I see the same thing as before, no new 
information (just that lone ranger L2A sitting in the middle of nowhere).
<!-- Author: Sal -->


<!-- Date: Tue Mar 30 16:05:39 2004 -->
<P> 
<Big> BitReporter / ADCMon / DSErrorMonitor Monitoring studies </Big> 
 
<P> 
I've been looking at the data taken before and after the shutdown with  
<A HREF = "http://www-cdfonline.fnal.gov/internal/usr/lmiller/cgi-bin/errmon/makepage.pl?beginrun=03%2F10%2F04&endrun=03%2F31%2F04&errors=Custom&custom=1%2C2%2C3%2C4%2C6%2C7%2C8%2C9%2C10%2C11%2C13%2C14%2C15%2C17%2C18%2C19%2C20%2C21%2C22%2C23%2C24%2C25%2C26%2C27&least_rate=1&lea"> 
pre-post shutdown bitreporter</A>.  The notable increases in errors between runs before and after the shutdown I see are: 
<P> 
f312: Occ out of limits 
<br> 
e033 
<br> 
e052: Mean out of limits 
<br> 
e132: Pipeline out of synch, chip 88 cap id  
<br> 
e372: out of hw db  
<br> 
e524: Occ out of limits 
<br> 
e152: bit 5, known flaky 
<br> 
e364: Stuck cell id, pipeline out of synch 
<P> 
 
A few seem to have improved a bit, although with only 5 runs post-shutdown, intermittant problems could be fooling me: 
<P>   
f450, e2b4, e4a2, e564. 
<P> 
 
I would ask the detector group to cross-check this list with theirs and have a look at these guys in more detail. 
 
<P>  
<!-- Author: bbrau -->


<!-- Date: Tue Mar 30 16:15:26 2004 -->
<h3>SRC Setup For L2 W/O L1</h3> 
I have set up the SRC to look at the "pre L1A/L2A/L2R" signals 
(TAXI ABLE 0) to see if the TSI emulator is sending junk signals to the SRC. The scope downstairs is now working properly, as explained above. I am triggering on the same thing as before, but now we have additional information.
<!-- Author: Sal -->

<!-- Date: Tue Mar 30 17:41:13 2004 -->
Entered in Silicon database: <ul>
<li>Ladder: SB1W4L2 
<li>problem n: 1234 
<li>Status: needs_observation
<li>Type: Unknown
<li>Action: Monitoring
<li>entered by: rahaman 
<li>description is: There is bump in the ADC distribution at 55-60. Run 181029. 
<li>See <a href="http://www-cdfonline.fnal.gov/internal/usr/lmiller/cgi-bin/newproblemdb/DBreport.pl?detsys=SVX&wedge=B1W4&layer=L2">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Tue Mar 30 18:46:28 2004 -->
<p><font size=+1> D-mode Calibration Job Started </font>
<p><pre>
Job id            : 320
Calibration type  : standard
Run period tag    : Mar_2004
DPS-off run       : 179874
DPS-on run        : 179873
Requested by      : Jason
Main process id   : 48022547
</pre>
<!-- Author: CDF silicon D-mode calibration job server v1.4 -->


<!-- Date: Tue Mar 30 18:46:45 2004 -->
<p><font size=+1> D-mode Calibration Job Finished </font>
<p><pre>
This is a computer-generated silicon D-mode calibration status report.
Silicon D-mode calibration job 320 FAILED.

Job info
--------
Calibration type : standard
DPS-off run      : 179874
DPS-on run       : 179873
Requested by     : Jason
Submitted        : 2004-03-30 18:46:09
Completed        : 2004-03-30 18:46:28
Status           : FAILURE

Last processing stage reported : start of the run_calib_analysis.tcl script
Failure diagnostics :
You have no controlling tty and no DISPLAY.  Cannot read passphrase.
</pre>
<!-- Author: D-mode script run_calib_analysis.tcl -->



<!-- Date: Wed Mar 31 00:13:59 2004 -->
<pre>RF station trips and sends abort gap losses to 40kHz (see plot in main elog). Si is put to STBY by the shift crew. RF station is recovered immediately and losses are back to normal. SI back to ON.</pre>
<!-- Author: julia -->

<!-- Date: Wed Mar 31 10:10:45 2004 -->
<p><font size=+1> D-mode Calibration Job Started </font>
<p><pre>
Job id            : 321
Calibration type  : standard
Run period tag    : Mar_2004
DPS-off run       : 179874
DPS-on run        : 179873
Requested by      : Jason
Main process id   : 50306017
</pre>
<!-- Author: CDF silicon D-mode calibration job server v1.4 -->


<!-- Date: Wed Mar 31 11:30:18 2004 -->
Entered in Silicon database: <ul>
<li>Ladder: IB4W3L2 
<li>problem n: 1175 
<li>Status: needs_observation
<li>Type: AVDD
<li>Action: IMON_limits
<li>entered by: thom 
<li>description is: <pre>avdd jump back to ~1090</pre><table border=1>
<tr><th>IMON LIMITS</th><th>Old</th><th>New</th></tr>
<tr><td><b>Nominal</b></td><td>1280</td><td>1085</td></tr>
<tr><td><b>Lower</b></td><td>1160</td><td>1075</td></tr>
<tr><td><b>Upper</b></td><td>1095</td><td>1190</td></tr></table> 
<li>See <a href="http://www-cdfonline.fnal.gov/internal/usr/lmiller/cgi-bin/newproblemdb/DBreport.pl?detsys=ISL&wedge=B4W3&layer=L2">report</a></ul>
<!-- Author: Problem DB -->



<!-- Date: Wed Mar 31 11:32:14 2004 -->
<h2> Silicon cooling trip </h2> <p> 
<li> water alarm in the control room ~9:30am 
<li> a few minutes after, ISL sono alarm - verfied that ISL was tripped OFF 
<li> a few minute later, SVX and L00 follow suit - this time Gui shows SVX and L00 still green, although IMON shows everything in trip state  
<li> hit silicon rack crash button just to be sure - right after GUI also reports SVX and L00 off, so proably was not necessary 
<li> Cryo people have some trouble to get crates reset - quadlog errors needed to be reset. 
<li> powered silicon back to standby without problems - now taking data.  
<!-- Author: Eva, Julia, Marcel, Sal, Rainer -->
<!-- Comment: Wed Mar 31 11;33;38 comment by...rainer -->
IFIX logfile for the curious:
<pre>
03/31/2004 08:41:39.4 [HTRDATA ]  HTCWATCHDOGTIMER                BLOCK IS RESET                                                    
03/31/2004 08:41:56.9 [CDFS5   ] C_FS_CGSC3W                    COS             CLOSE      Corken #3 water flow switch             
03/31/2004 08:42:10.4 [HTRDATA ]  HTCWATCHDOGTIMER                BLOCK IS RESET                                                    
03/31/2004 08:42:32.9 [CDFS5   ] C_FS_CGSC3W                    COS              OPEN      Corken #3 water flow switch             
03/31/2004 08:42:41.4 [HTRDATA ]  HTCWATCHDOGTIMER                BLOCK IS RESET                                                    
03/31/2004 08:42:51.9 [CDFS5   ] C_FS_CGSC3W                    COS             CLOSE      Corken #3 water flow switch             
03/31/2004 08:43:12.4 [HTRDATA ]  HTCWATCHDOGTIMER                BLOCK IS RESET                                                    
03/31/2004 08:43:43.4 [HTRDATA ]  HTCWATCHDOGTIMER                BLOCK IS RESET                                                    
03/31/2004 08:44:09.9 [CDFS5   ] C_FS_CGSC3W                    COS              OPEN      Corken #3 water flow switch             
03/31/2004 08:44:14.4 [HTRDATA ]  HTCWATCHDOGTIMER                BLOCK IS RESET                                                    
03/31/2004 08:44:12.9 [CDFS5   ] C_FS_CGSC3W                    COS             CLOSE      Corken #3 water flow switch             
03/31/2004 08:44:25.9 [CDFS5   ] C_FS_CGSC3W                    COS              OPEN      Corken #3 water flow switch             
03/31/2004 08:44:34.9 [CDFS5   ] C_FS_CGSC3W                    COS             CLOSE      Corken #3 water flow switch             
03/31/2004 08:44:45.4 [HTRDATA ]  HTCWATCHDOGTIMER                BLOCK IS RESET                                                    
[...]
</pre>
<i>Corken #3 thing happens a couple of times </i>
<pre>
[...]
03/31/2004 09:27:04.9 [CDFS5   ] C_FS_CGSC3W                    COS              OPEN      Corken #3 water flow switch             
03/31/2004 09:27:07.9 [CDFS5   ] C_FS_CGSC3W                    COS             CLOSE      Corken #3 water flow switch             
03/31/2004 09:27:37.4 [HTRDATA ]  HTCWATCHDOGTIMER                BLOCK IS RESET                                                    
03/31/2004 09:28:08.4 [HTRDATA ]  HTCWATCHDOGTIMER                BLOCK IS RESET                                                    
03/31/2004 09:28:39.4 [HTRDATA ]  HTCWATCHDOGTIMER                BLOCK IS RESET                                                    
03/31/2004 09:28:51.9 [CDFS5   ] C_FS_CGSC3W                    COS              OPEN      Corken #3 water flow switch             
03/31/2004 09:28:54.9 [CDFS5   ] C_FS_CGSC3W                    COS             CLOSE      Corken #3 water flow switch             
03/31/2004 09:29:02.9 [CDFS5   ] C_FS_CGSC3W                    COS              OPEN      Corken #3 water flow switch             
03/31/2004 09:29:10.4 [HTRDATA ]  HTCWATCHDOGTIMER                BLOCK IS RESET                                                    
03/31/2004 09:29:41.4 [HTRDATA ]  HTCWATCHDOGTIMER                BLOCK IS RESET                                                    
03/31/2004 09:30:12.4 [HTRDATA ]  HTCWATCHDOGTIMER                BLOCK IS RESET                                                    
<font color=black><b> 
</pre><i> Now ISL interlocks are dropped </i> <pre>
03/31/2004 09:30:21.7 [SVXIICON] ISL_C2303                      CFN              TRIP      PS TRIP/DISABLED ISL-E-Out              
03/31/2004 09:30:21.7 [SVXIICON] ISL_C2306                      CFN              TRIP      PS TRIP/DISABLED ISL-W-In               
03/31/2004 09:30:21.7 [SVXIICON] ISL_C2307                      CFN              TRIP      PS TRIP/DISABLED ISL-W-Cntr             
03/31/2004 09:30:21.7 [SVXIICON] ISL_C2308                      CFN              TRIP      PS TRIP/DISABLED ISL-W-Out              
03/31/2004 09:30:21.7 [SVXIICON] ISL_C2302                      CFN              TRIP      PS TRIP/DISABLED ISL-E-Cntr             
03/31/2004 09:30:21.7 [SVXIICON] ISL_C2301                      CFN              TRIP      PS TRIP/DISABLED ISL-E-In               
</b></font></pre> <i>...because ISL chiller  went OFF </i>
<pre>
<font color=red><b>03/31/2004 09:30:25.7 [SVXIICON] ISL_C2801                      CFN               BAD      ISL Chiller Status                      
03/31/2004 09:30:37.7 [SVXIICON] ISL_CHL_COMP_STATE             CFN               OFF      STATE OF ISL CHILLER COMPRESSOR</font></b><font color=black>
 </pre><i>  same thing for SVX </i><pre><b>
03/31/2004 09:30:43.4 [HTRDATA ]  HTCWATCHDOGTIMER                BLOCK IS RESET                                                    
03/31/2004 09:31:00.7 [SVXIICON] SVX_C1301                      CFN              TRIP      PS TRIP/DISABLED SVX-BHE1               
03/31/2004 09:31:00.7 [SVXIICON] SVX_C1302                      CFN              TRIP      PS TRIP/DISABLED SVX-BHE2               
03/31/2004 09:31:00.7 [SVXIICON] SVX_C1303                      CFN              TRIP      PS TRIP/DISABLED SVX-BHE3               
03/31/2004 09:31:00.7 [SVXIICON] SVX_C1304                      CFN              TRIP      PS TRIP/DISABLED SVX-BHW1               
03/31/2004 09:31:00.7 [SVXIICON] SVX_C1305                      CFN              TRIP      PS TRIP/DISABLED SVX-BHW2               
03/31/2004 09:31:00.7 [SVXIICON] SVX_C1306                      CFN              TRIP      PS TRIP/DISABLED SVX-BHW3               
03/31/2004 09:31:04.7 [SVXIICON] ISL_PS_TRIP                    CFN              TRIP      B5W5 Port Cd, maybe others              
03/31/2004 09:31:04.7 [SVXIICON] L00_PS_TRIP                    CFN              TRIP      B1W5 Port Cd, maybe others              
03/31/2004 09:31:04.7 [SVXIICON] SVX_PS_TRIP                    CFN              TRIP      B5W11 Port Cd, maybe others             
03/31/2004 09:31:05.7 [SVXIICON] L00_C3301                      CFN              TRIP      PS TRIP/DISABLED L00E                   
03/31/2004 09:31:05.7 [SVXIICON] L00_C3302                      CFN              TRIP      PS TRIP/DISABLED L00W                   
03/31/2004 09:31:08.7 [SVXIICON] SVX_C1801                      CFN               BAD      SVX Chiller Status                      
</font>
<font color=red> <b>
03/31/2004 09:31:14.4 [HTRDATA ]  HTCWATCHDOGTIMER                BLOCK IS RESET                                                    
03/31/2004 09:31:20.7 [SVXIICON] SVX_CHL_COMP_STATE             CFN               OFF      STATE OF SVX CHILLER COMPRESSOR         
</b></font>  
03/31/2004 09:31:18.9 [CDFS5   ] GEN3_IT_ALM                    COS             ALARM      generator3, current alarm               
03/31/2004 09:31:24.0 [CDF_S1  ] R_SOUND_ALM                    COS       RACKS ALARM      Sound Rack Alarm - CDF3                 
03/31/2004 09:31:23.9 [CDFS5   ] GN_SOUND_ALM                   COS             ALARM      generator sound alarm                   
03/31/2004 09:31:35.9 [CDFS5   ] GN_NO_ALM                      COS             ALARM      generator no alarm                      
03/31/2004 09:31:37.0 [CDF_S1  ] R_SOUND_ALM                    COS                        Sound Rack Alarm - CDF3                 
03/31/2004 09:31:35.9 [CDFS5   ] GN_VISUAL_ALM                  COS             ALARM      generator visual alarm                  
03/31/2004 09:31:35.9 [CDFS5   ] GN_SOUND_ALM                   COS               OK.      generator sound alarm                   
03/31/2004 09:31:45.4 [HTRDATA ]  HTCWATCHDOGTIMER                BLOCK IS RESET                                                    
03/31/2004 09:31:43.0 [CDF_S1  ] R_SOUND_ALM                    COS       RACKS ALARM      Sound Rack Alarm - CDF3                 
03/31/2004 09:31:53.0 [CDF_S1  ] R_SOUND_ALM                    COS                        Sound Rack Alarm - CDF3                 
03/31/2004 09:31:55.9 [CDFS5   ] C_FS_CGSC3W                    COS             CLOSE      Corken #3 water flow switch             
03/31/2004 09:31:57.9 [CDFS5   ] C_FS_CGSC3W                    COS              OPEN      Corken #3 water flow switch             
03/31/2004 09:32:03.9 [CDFS5   ] C_FS_CGSC3W                    COS             CLOSE      Corken #3 water flow switch             
03/31/2004 09:32:06.9 [CDFS5   ] C_FS_CGSC3W                    COS              OPEN      Corken #3 water flow switch             
03/31/2004 09:32:07.9 [CDFS5   ] GN_NO_ALM                      COS               OK.      generator no alarm                      
03/31/2004 09:32:07.9 [CDFS5   ] GN_VISUAL_ALM                  COS               OK.      generator visual alarm                  
03/31/2004 09:32:07.9 [CDFS5   ] GEN3_IT_ALM                    COS                OK      generator3, current alarm               
03/31/2004 09:32:07.9 [CDFS5   ] C_FS_CGSC3W                    COS             CLOSE      Corken #3 water flow switch             
03/31/2004 09:32:08.9 [CDFS5   ] C_FS_CGSC3W                    COS              OPEN      Corken #3 water flow switch   
</pre> what's the corken thing ??
          


<!-- Comment: Wed Mar 31 12;21;55 comment by...Jason -->
</B>
<!-- Date: Wed Mar 31 11:53:09 2004 -->
<pre>pinky s113 (avdd jumps up by 26mA, a few mA higher than upper limit). Everything else ok with this guy, so redefined upper limit from 840 to 850 mA. </pre>
<!-- Author: julia -->

<!-- Date: Wed Mar 31 12:19:15 2004 -->
<p><font size=+1> D-mode Calibration Job Started </font>
<p><pre>
Job id            : 322
Calibration type  : standard
Run period tag    : Mar_2004
DPS-off run       : 181095
DPS-on run        : 181094
Requested by      : Giorgio
Main process id   : 50370805
Comment           : standard cosmic trigger table
</pre>
<!-- Author: CDF silicon D-mode calibration job server v1.4 -->



<!-- Date: Wed Mar 31 12:56:22 2004 -->
<p><font size=+1> D-mode Calibration Job Started </font>
<p><pre>
Job id            : 323
Calibration type  : nonstandard
Run period tag    : Mar_2004
DPS-off run       : 181097
DPS-on run        : 181096
Requested by      : giorgio
Main process id   : 50576653
Comment           : using 443 instead of 441 as L3 tag
</pre>
<!-- Author: CDF silicon D-mode calibration job server v1.4 -->


<!-- Date: Wed Mar 31 12:56:22 2004 -->
<p><font size=+1> D-mode Calibration Job Started </font>
<p><pre>
Job id            : 323
Calibration type  : nonstandard
Run period tag    : Mar_2004
DPS-off run       : 181097
DPS-on run        : 181096
Requested by      : giorgio
Main process id   : 50576653
Comment           : using 443 instead of 441 as L3 tag
</pre>
<!-- Author: CDF silicon D-mode calibration job server v1.4 -->



<!-- Date: Wed Mar 31 14:14:09 2004 -->
<h2> Glink Synch Fest </h2><br>
<li> b0fib02 FFO Glink unsynched itself, and all attached ladders  tripped on SPT 
<li> resetting the glink in SVXDAQ did not help - Test FIFO enabled no way 
<li> took down the rack from cryo area - still Test FIFO enabled no way 
<li> reset the whole SVX using SVXDAQ and that cured it. 

<!-- Author: Julia, Marcel, Rainer -->
<!-- Comment: Wed Mar 31 14;52;37 comment by...rainer -->
<li> at one time, a cold start did the job   - see 


<a href=
'/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=132&frame=2&anchor=11:38:13'>
here</a> 

<li> glink re-synched using <a href=
'http://www-cdfonline.fnal.gov/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=156&frame=2&anchor=21:46:18'>
powercycle </a> 

<li> joy and happiness due to a unsyched glink

<a href=
'http://www-cdfonline.fnal.gov/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=172&frame=2&anchor=21:24:09'>
here </a> 

<li> 

<a href=
'http://www-cdfonline.fnal.gov/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=171&frame=2&anchor=23:17:16'>
here </a>  a powercycle did NOT help (ignore the suggestion to reboot the b0svx0x crate - I was young and innocent then) the first time, but a 2nd time it worked. In this link, also advice from steve.
<li> quite entertaining and informative exchange between gino and steve about handshake to be found <a href='http://www-cdfonline.fnal.gov/cgi/elog/det-system-elog.pl?nb=silicon&action=copyentry&page=170&time=06:07:03'> here </a>




<!-- Comment: Wed Mar 31 15;16;29 comment by...rainer -->
<pre> 
Received Directive on /mapSVX/svx/vrb/06from /_b0fib05_14148368 at Wed Mar 31 10:33:13 CST 2004: Glink Synch
Received Directive on /mapSVX/svx/vrb/02from /_b0fib02_15222504 at Wed Mar 31 12:58:10 CST 2004: Glink Synch
Received Directive on /mapSVX/svx/vrb/02from /_b0fib02_15222504 at Wed Mar 31 12:58:12 CST 2004: Glink Synch
Received Directive on /mapSVX/svx/vrb/02from /_b0fib02_15222504 at Wed Mar 31 12:58:14 CST 2004: Glink Synch
Received Directive on /mapSVX/svx/vrb/02from /_b0fib02_15222504 at Wed Mar 31 12:58:16 CST 2004: Glink Synch
Received Directive on /mapSVX/svx/vrb/02from /_b0fib02_15222504 at Wed Mar 31 12:58:18 CST 2004: Glink Synch
Received Directive on /mapSVX/svx/vrb/02from /_b0fib02_15222504 at Wed Mar 31 12:58:20 CST 2004: Glink Synch
Crate b0fib02 -> FIB_SVX_02 started at Wed Mar 31 13:10:15 CST 2004 Boot Time: WED MAR 31 13:10:11 2004
Loading Message
Received Directive on /mapSVX/svx/vrb/02from /_b0fib02_14148368 at Wed Mar 31 13:10:19 CST 2004: Glink Synch
Received Directive on /mapSVX/svx/vrb/02from /_b0fib02_14148368 at Wed Mar 31 13:10:21 CST 2004: Glink Synch
Received Directive on /mapSVX/svx/vrb/02from /_b0fib02_14148368 at Wed Mar 31 13:10:23 CST 2004: Glink Synch
Received Directive on /mapSVX/svx/vrb/02from /_b0fib02_14148368 at Wed Mar 31 13:10:25 CST 2004: Glink Synch
Received Directive on /mapSVX/svx/vrb/02from /_b0fib02_14148368 at Wed Mar 31 13:10:27 CST 2004: Glink Synch
Received Directive on /mapSVX/svx/vrb/02from /_b0fib02_14148368 at Wed Mar 31 13:10:29 CST 2004: Glink Synch
Crate b0fib02 -> FIB_SVX_02 started at Wed Mar 31 13:39:47 CST 2004 Boot Time: WED MAR 31 13:39:37 2004
Loading Message
Received Directive on /mapSVX/svx/vrb/02from /_b0fib02_14148368 at Wed Mar 31 13:39:52 CST 2004: Glink Synch
Received Directive on /mapSVX/svx/vrb/02from /_b0fib02_14148368 at Wed Mar 31 13:39:54 CST 2004: Glink Synch
Received Directive on /mapSVX/svx/vrb/02from /_b0fib02_14148368 at Wed Mar 31 13:39:56 CST 2004: Glink Synch
Received Directive on /mapSVX/svx/vrb/02from /_b0fib02_14148368 at Wed Mar 31 13:39:58 CST 2004: Glink Synch
Received Directive on /mapSVX/svx/vrb/02from /_b0fib02_14148368 at Wed Mar 31 13:40:00 CST 2004: Glink Synch
Received Directive on /mapSVX/svx/vrb/02from /_b0fib02_14148368 at Wed Mar 31 13:40:02 CST 2004: Glink Synch
Received Directive on /mapSVX/svx/vrb/02from /_b0fib00_14148368 at Wed Mar 31 13:50:31 CST 2004: Glink Synch
Received Directive on /mapSVX/svx/vrb/02from /_b0fib04_14148368 at Wed Mar 31 13:51:14 CST 2004: Glink Synch </pre>
</pre>
<!-- Comment: Wed Mar 31 15;20;45 comment by...rainer -->
unsynch'ed status is coincident with RESET/PARTTIONING 
of Run <a href='http://www-cdfonline.fnal.gov/java/cdfdb/servlet/RunSummary?RUN_NUMBER=181097'> 181097 </a>, a  DPS OFF compressed trigger table
dmod calibraiton run.
<!-- Date: Wed Mar 31 15:12:14 2004 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-3713&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-3713  width='300' align='top'></a></td><td>This shows the IMON status after the software protection trips at 13:01 
</td></tr></table>
<!-- Author: Marcel -->
<!-- Comment: Wed Mar 31 15;17;06 comment by...Marcel -->
<h3> GLINK Fest preshow</h3>
The whole thing started with a software protection trip of b0fib02 ladders. So this what started it all.

<!-- Date: Wed Mar 31 15:14:36 2004 -->
<h2> Compression in dmod tested </h2> 
 
<li><a href='http://www-cdfonline.fnal.gov/java/cdfdb/servlet/RunSummary?RUN_NUMBER=181094'> 181094 </a>  DPS ON  normal uncompressed trigger table ~ 15min 
<li> 
<a href='http://www-cdfonline.fnal.gov/java/cdfdb/servlet/RunSummary?RUN_NUMBER=181095'> 181095 </a> DPS OFF normal uncompressed trigger table ~ 16min 
<li> 
<a href='http://www-cdfonline.fnal.gov/java/cdfdb/servlet/RunSummary?RUN_NUMBER=181096'> 181096</a> DPS ON  compressed trigger table ~13min 
 
<li><a href='http://www-cdfonline.fnal.gov/java/cdfdb/servlet/RunSummary?RUN_NUMBER=181097'> 181097</a> DPS OFF compressed trigger table ~ 13min 
  
<!-- Author: rainer -->





<!-- Date: Wed Mar 31 19:35:19 2004 -->
<pre>only 20mins of quiet time before shot setup, they'll tell me if there's a change.</pre>
<!-- Author: julia -->


<!-- Date: Wed Mar 31 23:08:00 2004 -->
<pre>again L2w/oL1 SRC error, Sal clears from home. Trigger did fire. 
</pre>
<!-- Author: julia -->
<!-- Comment: Wed Mar 31 23;14;00 comment by...julia -->
<pre>stored it in L2woL1_E file. Sal will look at it tomorrow.</pre>

<!-- Comment: Wed Mar 31 23;14;48 comment by...julia -->
<pre>this happened just before we were going to take data, so no "halt"</pre>


<!-- Date: Wed Mar 31 23:19:18 2004 -->
<pre>Store 3337. Problem again high LOSTP. At 17Khz now and pretty stable at that level (Aces are putting the plots in the elog now), but again spikey. MCR is having "an eye on it". Si on.</pre>
<!-- Author: julia -->


<!-- Date: Wed Mar 31 23:36:41 2004 -->
<pre>Called MCR: they're doing the standard tuning but I don't see a change. 
We can run like this, although it's not pretty: spikes to 25kHz and mean at 18kHz. They'll call if they decide to rescrape..</pre>
<!-- Author: julia -->


<!-- Date: Wed Mar 31 23:54:33 2004 -->
<pre>I'm still bugging MCR. They have found the problem: one of the collimators didn't move. They'll call us before they start moving it.</pre>
<!-- Author: julia -->


<!-- Date: Thu Apr 1 00:03:48 2004 -->
<pre>Si in STBY. MCR is starting to move the collimator.</pre>
<!-- Author: julia -->


<!-- Date: Thu Apr 1 00:37:19 2004 -->
<pre>MCR is done. The collimator moved a lot, but ess. no change to LOSTP. PAGC cleaned out. We're going back to ON.</pre>
<!-- Author: julia -->


<!-- Date: Thu Apr 1 10:52:56 2004 -->
<pre>MCR plan: store kept until 7pm and probably 2h access for D0. 
</pre>
<!-- Author: julia -->


<!-- Date: Thu Apr 1 15:56:00 2004 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-3714&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-3715  width='300' align='top'></a></td><td>AVDD for SB1W8L4 after at Quench. Could be a possible flakey AVDD2 failure.</td></tr></table>
<!-- Author: David -->
<!-- Comment: Thu Apr  1 16;30;29 comment by...rainer -->
<pre>also failed config after post quench checkout - recovery of current is due to SVXDAQ RA running. after that, ladder initializes correctly.</pre>
<!-- Comment: Thu Apr  1 20;28;19 comment by...rainer -->
<h2> this was an pbar abort kicker prefire</h2>MCR <a href='http://www-bd.fnal.gov/cgi-mcr/elog.pl?nb=2004&action=view&page=-1464'> elog </a>
<!-- Comment: Thu Apr  1 20;30;43 comment by...rainer -->
Doses etc. 

<a href=
'http://www-cdfonline.fnal.gov/cgi/elog/elog.pl?nb=2004&action=view&page=198&frame=2&anchor=15:40:12.339'>
here</a> 

<!-- Date: Thu Apr 1 16:12:44 2004 -->
<table><tr><td><a href=/elog/notebooks/silicon/Thu_Apr__1_2004_161240.ps align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-3717  align='top'></a></td><td>SRC error (finally). L2A, no pre-L2A from tsi. 
I have to think about this...</td></tr></table>
<!-- Author: Sal -->
<!-- Comment: Thu Apr  1 16;14;25 comment by...Sal -->
<table border=0><td><tr><td bgcolor=#e0e030><b>On the next SVX thermal cycle, please page Sal (722-7599)
so I can swap the LA ports to look at the TSI emulator
commands.</b></td></tr></td></table>
<!-- Comment: Thu Apr  1 16;31;20 comment by...Sal -->
So since the "pre-L2A" (i.e. the L2A into the
TAXI chip before it is clocked out to the RSM)
is not being sent, I think we have localized the
problem to the RSM. This seems to happen more
often on or after ABORT.
<br><br>
I will pore over the RSM schematics to figure out what
this could be from.
<!-- Comment: Thu Apr  1 17;18;25 comment by...Sal -->
Whoops. Lester tells me that Pre-L2A is after the TAXI chip.
It is then clocked in by the RSM. The L2A signal is
immediately after the RSM clocks it in, so the problem is
in what is driving the L2A command (either the taxi or
the tsi emulator). I will check over the
firmware we have changed.
<br><br>
<b>The next power cycle may need to include a small
firmware upgrade to put in more descriptive LA ports out
of the TSI emulator.</b>
<!-- Date: Thu Apr 1 16:14:06 2004 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-3718&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-3719  width='300' align='top'></a></td><td>Looks like AVDD2 is back for SB0W8L4.</td></tr></table>
<!-- Author: David -->



<!-- Date: Thu Apr 1 16:20:34 2004 -->
<center><a href='/elog/notebooks/silicon/Thu_Apr__1_2004_161929.ps'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-3721' ></a><a href='/elog/notebooks/silicon/Thu_Apr__1_2004_161940.ps'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-3723' ></a><a href='/elog/notebooks/silicon/Thu_Apr__1_2004_161947.ps'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-3725' ></a><a href='/elog/notebooks/silicon/Thu_Apr__1_2004_162019.ps'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-3727' ></a></center>
<!-- Author: rainer -->
<!-- Comment: Thu Apr  1 16;29;21 comment by...rainer -->
e084 drops readout after the first 3 chips, 8a has capid issue:<pre>
e084 70fc 8d09 00f3 
          8c09 
          8b09 32f3 332c 34f3 
          8a01 c1bd
e090 70fc        

e084 09fc 8d00 00f3 
          8c00 
          8b00 
          8a01 c1b9 e090 09fc
</pre>

<!-- Date: Thu Apr 1 16:29:20 2004 -->
Entered in Silicon database: <ul>
<li>Ladder: SB0W8L4 
<li>problem n: 1228 
<li>Status: needs_work
<li>Type: AVDD2
<li>Action: Diagnosis_update
<li>entered by: rainer 
<li>description is: DRO at 0x8a seen in cosmics running after pbar prefire: <pre> e084 09fc 8d00 00f3 8c00 8b00 8a01 c1b9 e090 09fc </pre> 
<li>See <a href="http://www-cdfonline.fnal.gov/internal/usr/lmiller/cgi-bin/newproblemdb/DBreport.pl?detsys=SVX&wedge=B0W8&layer=L4">report</a></ul>
<!-- Author: Problem DB -->







<!-- Date: Thu Apr 1 17:37:15 2004 -->
<h3>SB2W2L4 LV Cable Probe</h3> 
Probed the LV cables to try to determine why this guy persistently trips on DVDD.  Made the following measurements 
<table border="1" cellpadding="1" cellspacing="1"> 
<tr> 
<th>PINS</th> 
<th>L4 (MOhms)</th> 
<th>L3 (MOhms)</th> 
</tr> 
<tr> 
<td>DVP-DVN</td> 
<td>1.8/2.8</td> 
<td>1.8/2.8</td> 
</tr> 
<tr> 
<td>AVN-AVP</td> 
<td>0.56/0.64</td> 
<td>0.94/1.16</td> 
</tr> 
<tr> 
<td>5VDP-5VDN</td> 
<td colspan="2"><center>19.0/OL</center></td> 
</tr> 
</table> 
The readings for the AVDD look a little low but that seems strange that this would cause DVDD trips.  Need to compare these measurements with those that were made on e440 to see if any conclusions can be drawn. 
 
<h3>SB1W4L4 HV cable probe</h3> 
Investigating the possibility of a pin-hole on this guy. Measured the Bias cable resistance to see what we could learn. 
<table border="1" cellpadding="1" cellspacing="1"> 
<tr> 
<th>PINS</th> 
<th>L4 (kOhms)</th> 
<th>L3 (kOhms)</th> 
</tr> 
<tr> 
<td>+/-</td> 
<td>58.5/Charging OL</td> 
<td>46/84</td> 
</tr> 
<tr> 
<td>+/RF</td> 
<td>OL</td> 
<td>OL</td> 
</tr> 
<tr> 
<td>-/RF</td> 
<td>OL</td> 
<td>OL</td> 
</tr> 
</table> 
It looks like the L4 bias is a little low and has some charging overload that is not present in the L3 measurements.  Is this what we expect from a pin-hole?
<!-- Author: reid and stan -->
<!-- Comment: Fri Apr  2 09;59;15 comment by...reid -->
<pre>Matt reminds me that L4 bias should be compared to L2 as these are both Micron layers.  The results of the SB1W4L4 probe therefore are most likely what we expect.  </pre>
<!-- Comment: Thu Apr 15 10;55;04 comment by...Jared, David -->
<pre>&lt;a href=
'/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=171&frame=2&anchor=07:50:16'&gt;
Compare to HV probe summary &lt;/a&gt;
</pre>
<!-- Date: Thu Apr 1 18:54:11 2004 -->
<h2> possible recent prefires</h2> <p> 
<li> Sat Nov 29th 2003 <a href=' 
http://www-bd.fnal.gov/cgi-mach/machlog.pl?nb=tev03&action=view&page=435&anchor=113343&hilite=11:33:43-'> 1140am</a> Silicon was in Standby. 
<li> Sat Mar 1st 2003 
<a href='http://www-bd.fnal.gov/cgi-mcr/elog.pl?nb=2003&action=view&page=163&anchor=Start%2Bof%2BShift&hilite=PREFIRE'> 0948am </a> silicon was in standby, but ladders tripped out of standby. 
<li>  Mon Feb 10th 2003 <a href='http://www-bd.fnal.gov/cgi-mcr/elog.pl?nb=2003&action=view&page=111&anchor=Start%2Bof%2BShift&hilite=PREFIRE'> 2152pm </a> silicon was OFF.
<!-- Author: rainer -->




<!-- Date: Fri Apr 2 00:34:58 2004 -->
<pre>store 3341: RF station lost just before the store. Instructed the Ace to watch the abort gap losses. LOSTP better than last few times, 15kHz. PAGC started out at 12kHz and dropped to 10kHz, probably due to D0 pots movement.</pre>
<!-- Author: julia -->


<!-- Date: Fri Apr 2 00:50:57 2004 -->
<table><tr><td><a href=/elog/notebooks/silicon/Fri_Apr__2_2004_005048.ps align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-3729  align='top'></a></td><td>map for run 181190 ok</td></tr></table>
<!-- Author: julia -->


<!-- Date: Fri Apr 2 07:17:33 2004 -->
<pre>several magnets quench at 6:06am. Radiation alarm (beam abort) alarm sounds and Aces hit the crash button after they hit STBY in IFIX (they thought the GUI didn't respond) 
Ricardo's assessent: east side was hit with high radiation (don't know yet how much). West side is ok. 
There were no trips in the silicon. 
We're keeping the Si off for Sal to work on SRC firmware and LA ports. There will be an unknown amount of quiet time.</pre>
<!-- Author: julia -->
<!-- Comment: Fri Apr  2 13;20;09 comment by...rainer -->
<h2> quench of unknown origin </h2> this 
<a href=
'http://www-cdfonline.fnal.gov/cgi/elog/elog.pl?nb=2004&action=view&page=200&frame=2&anchor=07:48:48.877'>
morning.</a> 

<!-- Date: Fri Apr 2 08:22:05 2004 -->
<pre>while SI is still off the ISL cooling alarm goes off. ISL CCM3 1OUT is shooting up to 80 degrees. We make sure the power is really off. The ISL flow is good, no problems seen anywhere except in that sensor. Andy remembers this sensor is wacky and will come in to check it.</pre>
<!-- Author: julia -->
<!-- Comment: Fri Apr  2 08;28;20 comment by...rainer -->

<a href=
'http://www-cdfonline.fnal.gov/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=113&frame=2&anchor=02:47:20'>
user link text </a> 

<!-- Date: Fri Apr 2 08:23:12 2004 -->
<pre>-paged Sal for SRC work 
-paged David for quiet time study after Sal is done</pre>
<!-- Author: julia -->



<!-- Date: Fri Apr 2 08:42:40 2004 -->
<center><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-3730&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-3731' ></a></center>
<!-- Author: rainer,julia -->
<!-- Comment: Fri Apr  2 08;44;04 comment by...rainer -->
ISL_TE_CCW2L6_1OUT acting up.

<!-- Comment: Fri Apr  2 08;53;23 comment by...rainer -->
came down by itself. previous incidents:
<li> 

<a href=
'http://www-cdfonline.fnal.gov/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=78&frame=2&anchor=09:14:40'>
Sat Nov 17,2002 09:14</a>
<li> 

<a href=
'http://www-cdfonline.fnal.gov/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=76&frame=2&anchor=13:46:06'>
Wed Nov 14 ,2002 13:46:06</a> 

<a href=
'http://www-cdfonline.fnal.gov/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=113&frame=2&anchor=02:47:20'>
 <li>
<a href=
'http://www-cdfonline.fnal.gov/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=113&frame=2&anchor=02:47:20'>
Tue Jun 18,2003 02:47:20 </a> 
 
<li> 



<!-- Date: Fri Apr 2 11:00:38 2004 -->
Entered in Silicon database: <ul>
<li>Ladder: IB5W5L1 
<li>problem n: 1182 
<li>Status: needs_access
<li>Type: Chip_bit_error
<li>Action: Diagnosis_update
<li>entered by: dkclark 
<li>description is: Ran with SVXDAQ and confirmed the bit 1 high and low problems in chips 9b->b4 (all of the 2nd halfladder).  Also confirmed that the VRB is OK by swapping glinks in VTM. This is most likely internal, but should be confirmed  that the FIB crate is not the culprit by swapping DOIM cables in next access. 
<li>See <a href="http://www-cdfonline.fnal.gov/internal/usr/lmiller/cgi-bin/newproblemdb/DBreport.pl?detsys=ISL&wedge=B5W5&layer=L1">report</a></ul>
<!-- Author: Problem DB -->



<!-- Date: Fri Apr 2 11:04:39 2004 -->
<h3>SRC Checkout</h3> 
<ul> 
<li>I modified 
the SRC TSI_EM firmware to include some more debugging tools coming 
out of the TSI_EM port to catch this L2 w/o L1 problem.</li> 
<li> I found that the TSI_EM chip was labelled "TSI26", which 
is the "old" naming convention. The current TSI_EM prom 
is TSI_EM_6 (as shown in my 
<a href="harv11.fnal.gov/~rappocc/src/mcs/mcs.html"> web page</a>). 
This could explain some problems. <b> I will look at the actual 
MCS file in the chip to check the firmware itself and be sure.</b></li> 
<li> I swapped the firmware, and also swapped the MCLOCK 
LA port to the TSI_EM port. I did leave the CLK line from 
the LA on the MCLOCK pin 4 to keep looking at that.</li> 
<li> Started the SRC checkout</li> 
<ul> 
  <li> SRC Internal Logic (signals from TSI_EM) 
    <ul> 
       <li> L1A, L2A, L2R, Errors (2L1A + L2 w/o L1) okay </li> 
       <li> KEEPALIVES present in HALT/RECOVER/RUN/ERROR</li> 
    </ul> 
  </li> 
  <li> Run Data With SRC only (but talk to TS) 
    <ul> 
        <li> Disabled VRB handshake</li> 
        <li> Disabled J3 Commands 
        <li> Upon AUTOMATIC, we get a brake</li> 
        <li> <b><font color="red"> Also saw GLINKS not synched </font></b> 
         <ul> 
           <li> Downloaded standard.mclock again </li> 
           <li> Tried some combinations of rebooting crates</li> 
           <li> In the end, a RC config synched them all up</li> 
         </ul> 
        <li> Disabled Handbrake (SRC FIB Error mask 3)</li> 
        <li> AUTOMATIC ran fine, Digitize, Readouts present, 
              KEEPALIVES gone until you go to HALT. Upon RUN, 
              the rate is so high you don't see them</li> 
    </ul> 
  </li>   
  <li> Ran at low rate with a fib 
    <ul> 
       <li> Enabled J3 Commands again </li> 
       <li> Turned on VRB handshake</li> 
       <li> Keepalives present, Full readout present (DIG/RO/RB/SB)</li> 
    </ul> 
  </li> 
 
  <li> Ran the <b>PIGS!</b> 
    <ul> 
       <li> Keepalives present</li> 
       <li> Healthy readout chain </li> 
    </ul> 
  </li> 
  <li> Checked the new LA ports in Able 0. All is performing 
       as expected.</li> 
</ul> 
<li> <b><font color="blue">We are happily oinking pigs without further problems.</font></b> 
</li> 
</ul>
<!-- Author: David, Sal, Rainer -->
<!-- Comment: Fri Apr  2 15;06;35 comment by...Sal -->
The PROM in the SRC was actually the most up to date version
of the firmware, not an old version as was indicated by the label.
So it is unlikely that this will solve any problems. In any case,
we have further information available to us for the next time
this occurs.
<!-- Date: Fri Apr 2 12:14:24 2004 -->
Entered in Silicon database: <ul>
<li>Ladder: IB5W5L1 
<li>problem n: 1182 
<li>Status: needs_observation
<li>Type: Chip_bit_error
<li>Action: Diagnosis_update
<li>entered by: dkclark 
<li>description is: Swapped DOIM cables and confirmed that the bit 1 errors are internal.  Please look at ADCMON and determine if any of the chips (9b->b4) have physics. 
<li>See <a href="http://www-cdfonline.fnal.gov/internal/usr/lmiller/cgi-bin/newproblemdb/DBreport.pl?detsys=ISL&wedge=B5W5&layer=L1">report</a></ul>
<!-- Author: Problem DB -->



<!-- Date: Fri Apr 2 13:07:49 2004 -->
<center><a href='/elog/notebooks/silicon/Fri_Apr__2_2004_130556.ps'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-3733' ></a><a href='/elog/notebooks/silicon/Fri_Apr__2_2004_130609.ps'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-3735' ></a></center>
<!-- Author: rainer -->
<!-- Comment: Fri Apr  2 13;08;27 comment by...rainer -->
<pre>some problems in ISL which cleared after HRR.</pre>



<!-- Date: Fri Apr 2 15:23:37 2004 -->
<p><font size=+1> D-mode Calibration Job Started </font>
<p><pre>
Job id            : 324
Calibration type  : standard
Run period tag    : Apr_2004
DPS-off run       : 181224
DPS-on run        : 181223
Requested by      : olga
Main process id   : 57886648
</pre>
<!-- Author: CDF silicon D-mode calibration job server v1.4 -->


<!-- Date: Fri Apr 2 15:24:40 2004 -->
<p><font size=+1> D-mode Calibration Job Finished </font>
<p><pre>
This is a computer-generated silicon D-mode calibration status report.
Silicon D-mode calibration job 324 FAILED.

Job info
--------
Calibration type : standard
DPS-off run      : 181224
DPS-on run       : 181223
Requested by     : olga
Submitted        : 2004-04-02 15:23:24
Completed        : 2004-04-02 15:23:44
Status           : FAILURE

Last processing stage reported : start of the run_calib_analysis.tcl script
Failure diagnostics :
You have no controlling tty and no DISPLAY.  Cannot read passphrase.
</pre>
<!-- Author: D-mode script run_calib_analysis.tcl -->



<!-- Date: Sat Apr 3 03:00:20 2004 -->
<pre>beginning of store 3348. LOSTP going through the roof (40kHz). Turns out 4 collimators didn't move.  
</pre>
<!-- Author: julia -->


<!-- Date: Sat Apr 3 03:52:05 2004 -->
<pre>we've been watching the proton losses for an hour. We're now close to 20kHz and pretty stable, so let's take some data. MCR has been tuning. We're running with the old trigger tables and will switch during the day when we can get people to help.</pre>
<!-- Author: julia -->


<!-- Date: Sat Apr 3 06:35:30 2004 -->
<pre>?????????????????? 
strange trigger inhibit behaviour 
 
got paged with the report that svx trigger inhibit had fired but 
that no ladders had tripped. I came in to look at it, here's what 
seems to have happened: 
 
1)SVX trigger inhibit fired but no alarm, ifix zero bar. IFIX 
trigger inhibit window claims s260 as the cause. SVX wedge 26 
trip is reset by the ace (red in PS GUI but no message in 
window). 
 
2)then ISL and SVX trigger inhibit fired. ISL has no red in the 
 GUI and clears after a moment, SVX has red wedges s04-6, s14-6 
 and s24-6. Ace calls me.  
 
3)I arrive at B0, reset and power the red wedges without problem. The inhibit clears and run is resumed. 
 
Is this similar to the GUI weirdness reported earlier this year?? 
Downtime: 5:28am-5.59am, 31minutes.  
After reading the old elog entries, I should have made them start 
 a new run, in case these wedges were not powered from the 
 start..however I checked SVXMon before I left and it was fine,  
I would have seen this.. 
 
By the way, ISL cooling alarm was still silenced since the morning!</pre>
<!-- Author: julia -->
<!-- Comment: Sat Apr  3 07;05;05 comment by...julia -->
<pre>svxinter entries:

Sending Request for e266
Sending Request for e256
Sending Request for e246
com_int = 0
detector = 0, status = 0
Sending Request for e046
Module is busy, sending code = 16
Sending Request for e056
Sending Request for e066
Sending Request for e146
Sending Request for e156
Sending Request for e166
detector = 2, status = 0
Module is busy, sending code = 18
</pre>

<!-- Comment: Sat Apr  3 07;12;37 comment by...julia -->
<pre>PSGUI log file doesn't mention the trips. The first reset in the ace turning a wedge on, the second reset is me.

Sat Apr 03 03:53:04 CST 2004     IFix -  success: Silicon ON  
Sat Apr 03 05:30:50 CST 2004     success: Resetting trips
Sat Apr 03 05:36:06 CST 2004     success: Resetting trips
Sat Apr 03 05:37:16 CST 2004     success: Power Supply SVX B2 W6 ON
Sat Apr 03 05:56:02 CST 2004     success: Resetting trips
Sat Apr 03 05:56:13 CST 2004     success: Power Supply SVX B2 W5 ON
Sat Apr 03 05:56:26 CST 2004     success: Power Supply SVX B2 W4 ON
</pre>

<!-- Comment: Sat Apr  3 07;33;53 comment by...julia -->
<pre>Damn, is this the "third-of-the-month-crate-surprise"?
It's when a CAEN crate spontanously powers down, so no IFIX alarm, since it doesn't show up as "tripped", just as "off".</pre>


<!-- Comment: Sat Apr  3 10;44;24 comment by...rainer -->
<li>yes. this was crate #5 SWB Top malfunction as you can read off by the wedges affected using the web page 
<a href='http://www-cdf.fnal.gov/upgrades/svxii/caen/PSstatus.html'> here </a>. 
<li> it's not clear from your entry whether you found ALL these 9 wedges OFF (red) when you came in or only some were red when they called you. in this case it would have been an almost a clear hockerization case - press the reset button and re-power the crates. what was missing was proably the IFIX message about crate communication error. if you scroll up your svxinter history, I am sure you will find error messages complaining about crate #5.
<li> the weirdness comes in if the GUI is happy (ALL green) and still there is a trigger inhibit. in this case there is a faulty readback (A zero is taken as a legal bias voltage, but the the software inhibit of course disagrees) as has happened 
<a href=
'http://www-cdfonline.fnal.gov/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=180&frame=2&anchor=02:18:19'>
earlier</a>. there, the command cratematch.pl helps and the ifix trigger inhibit page to locate the culprit. it is then worthwhile to examine the currents read back from that guy. usually this results in a manual hockerization as well (power down all wedges, crate reset, power up again, readback fine).
<!-- Comment: Sat Apr  3 10;48;26 comment by...rainer -->
<pre>&lt;li&gt; PS - the software trigger inhibit prevents you from taking data so there is no harm. however, the software trigger inhibit takes a 60sec or so to fire, so the wedge could be off and for 60 sec or so you continue to take data. there is nothing you can do about it.</pre>
<!-- Comment: Sat Apr  3 11;03;14 comment by...rainer -->
<a href=
'http://www-cdfonline.fnal.gov/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=181&frame=2&anchor=09:01:09'>
here </a>
 and <a href=
'http://www-cdfonline.fnal.gov/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=181&frame=2&anchor=17:27:48'>
here</a>
 are mor eexamples.

<!-- Date: Sat Apr 3 08:02:13 2004 -->
<table><tr><td><a href=/elog/notebooks/silicon/Sat_Apr__3_2004_080205.ps align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-3739  align='top'></a></td><td>store 3348, run 181235</td></tr></table>
<!-- Author: julia -->


<!-- Date: Sat Apr 3 08:20:58 2004 -->
<pre>new trigger table test with Si: looks good, almost identical rates as before. </pre>
<!-- Author: julia -->
<!-- Comment: Sat Apr  3 22;50;21 comment by...julia -->
<pre>this is the one where only L3 cuts were changed</pre>
<!-- Date: Sat Apr 3 08:21:52 2004 -->
<pre>we'll get a dmod calibration later during the store. </pre>
<!-- Author: julia -->





<!-- Date: Sat Apr 3 15:06:57 2004 -->
<center><a href='/elog/notebooks/silicon/Sat_Apr__3_2004_150516.ps'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-3741' ></a><a href='/elog/notebooks/silicon/Sat_Apr__3_2004_150551.ps'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-3751' ></a></center>
<!-- Author: Marcel -->


<!-- Date: Sat Apr 3 15:13:04 2004 -->
<h2> Yobus Revenge</h2> 
I was paged because the SRC was in the usual L2 without L1 state  
. Sal's Fix worked nicely, however the LA showed some completely weird behaviour.  (see plots above) <br> 
 Basically all Signals went high (looked like a glitch or something) I would not confirm this  being a real L2 wo L1, maybe the LA triggered on something else. Anyway for further investigation, I saved it ( ending 040304 in the LA at the SRC crate)<br> 
So everyone interested may have a look at it. 
 
  
<!-- Author: Marcel -->
<!-- Comment: Sat Apr  3 16;32;42 comment by...Marcel -->
Before the run 181236 was stopped, a lot of <a href='http://www-cdfonline.fnal.gov/daq/runSummary/errorlog/errorfile181236_reformatter.log'>  Reformatter</a> Errors showed up. No FIB id shown, only <pre>
 0xc4c4f440  0xadeadcdf  </pre> like things.
Ray said the problems were centered arround b0fib05


<!-- Comment: Sun Apr  4 01;40;01 comment by...rainer -->
indeed there is a lot of garbage in the reformatter log files, but the one fragment might implicate FIB48 in b0fib05, see main
<a href=
'http://www-cdfonline.fnal.gov/cgi/elog/elog.pl?nb=2004&action=view&page=204&frame=2&anchor=13:43:18.408'>
 elog</a>. maybe the fib firmware got corrupted ? had b0fib05 been logged into, then it could have been told via <pre>
Sent ack to Run Control: 1 READY SUCCESS
State is READY
Fib Slot 17 MSRAM Corrupt (Calc - Expect) = fffffff0
Messenger: processStatechange Activate [0]
Starting run 179644 at 1078457709
Sent ack to Run Control: 1 ACTIVE SUCCESS
State is ACTIVE
</pre>
More info 
<a href=
'/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=106&frame=2&anchor=07:57:03'>
here </a>

<!-- Comment: Sun Apr  4 01;46;13 comment by...rainer -->
I conclude this because your fragment actually shows a (byte shiftedby a c4c4) fib id, f440. f441 is dead, so deadcdf is warranted, too, same for f443. <pre>

(MLE) b0l3pcom2.fnal.gov:main:1:35:25 PM->Error on L3 node b0l3194 (partition 1) Sat Apr 3 13:35:25 2004 
l3_node 
  in refoInt_reformatProc (l3_refevt.c:610)
  @L3_REFORMAT_ERROR

RAWREF Error - UTILSILDEC - with code 39 -- START
 Line - 1149 in: src/library/rr_rawevt.c
 Buffer position: 4147
 Error count: 1 of 1
 Reject rate: 0.012 percent

Detector ID not known (yet?).
 FIB ids found:
  0xc4c4f440  0xadeadcdf  0xc4c4f442  0xadeadcdf  0xc4c4c4c4  0xc4c4f450  0xc4c4f451  0xc4c4f452  0xc4c4f
453  0xc4c4f454
</pre>
<!-- Date: Sat Apr 3 22:49:22 2004 -->
<pre>this is what happened: 
1)aces ended a run 
2)they powercycled xtrp crate for new firmware 
3)they shepered the xtrp crate 
4)they went through a config 
5)ready came up green 
6)stuck on activate, they thought svx02 was stuck 
7)it wasn't clear that this was a "L2 w/o L1" (need an abort for that) they paged me, I was on my way 
8)rainer walked Jared through the SRC reset 
9)EVB was stuck, they cleared it 
 
Marcel looked at the LA trigger: as before, lonely L2A 
running with new trigger table (new L2) now, looks ok for silicon 
</pre>
<!-- Author: jared, julia, marcel -->
<!-- Comment: Sun Apr  4 01;42;02 comment by...rainer -->
more info
<a href=
'http://www-cdfonline.fnal.gov/cgi/elog/elog.pl?nb=2004&action=view&page=205&frame=2&anchor=21:49:07.639'>
here </a>
<!-- Date: Sat Apr 3 23:34:14 2004 -->
<pre>..and again!! 
 
L2w/oL1 again after trigger test ended. We reset it and store the LA trace.</pre>
<!-- Author: julia -->


<!-- Date: Sat Apr 3 23:40:01 2004 -->
<table><tr><td><a href=/elog/notebooks/silicon/Sat_Apr__3_2004_233951.ps align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-3753  align='top'></a></td><td>We caught Yobu again. He evaded me the first time (bad aiming on the LA buttons ...) 
The trace is saved and here comes the screen shot. The usual thing, Lonely L2 in the middle of nowhere </td></tr></table>
<!-- Author: Julia, Marcel -->




<!-- Date: Sun Apr 4 06:01:28 2004 -->
<h3>Jobu (Again)</h3>
The crew paged me in the evening. They got L2 w/o L1 again.
I reset it from home, and will check the trace later today.
Also, it is <font color="blue">not clear</font> whether nothing is
high in the scope traces, as there are other variables lower
in the list not shown on the screen.
<!-- Author: Sal, Marcel -->
<!-- Comment: Sun Apr  4 09;58;20 comment by...Sal -->
I have checked the traces, and the same thing occurred. L2A
in the middle of nowhere. Jobu is turning out to be an elusive
little bugger. I am going to change the LA ports to ABLE 1,
which might give us some more information.
<!-- Comment: Sun Apr  4 10;13;07 comment by...Sal -->
I switched the LA ports from TSI_EM Able 0 to TSI_EM Able 1.
<!-- Date: Sun Apr 4 06:25:17 2004 -->
<p><font size=+1> D-mode Calibration Job Started </font>
<p><pre>
Job id            : 325
Calibration type  : standard
Run period tag    : Apr_2004
DPS-off run       : 181253
DPS-on run        : 181251
Requested by      : Ingyin
Main process id   : 60271663
</pre>
<!-- Author: CDF silicon D-mode calibration job server v1.4 -->


<!-- Date: Sun Apr 4 06:25:18 2004 -->
<p><font size=+1> D-mode Calibration Job Finished </font>
<p><pre>
This is a computer-generated silicon D-mode calibration status report.
Silicon D-mode calibration job 325 FAILED.

Job info
--------
Calibration type : standard
DPS-off run      : 181253
DPS-on run       : 181251
Requested by     : Ingyin
Submitted        : 2004-04-04 06:23:50
Completed        : 2004-04-04 06:24:11
Status           : FAILURE

Last processing stage reported : start of the run_calib_analysis.tcl script
Failure diagnostics :
You have no controlling tty and no DISPLAY.  Cannot read passphrase.
</pre>
<!-- Author: D-mode script run_calib_analysis.tcl -->



<!-- Date: Sun Apr 4 06:27:39 2004 -->
<center><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-3754&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-3754' width='300'></a><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-3755&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-3755' width='300'></a></center>
<!-- Author: boveia -->
<!-- Comment: Sun Apr  4 06;33;42 comment by...boveia -->
<pre>persistent pink on SB5W6L1 caused by the AVDD current sneaking up above the threshold.  this came with a DVDD drop ~5 mA.  julia says she'll take care of it later today.</pre>


<!-- Date: Sun Apr 4 07:57:45 2004 -->
<center><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-3757&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-3757' width='300'></a><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-3756&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-3756' width='300'></a></center>
<!-- Author: boveia -->
<!-- Comment: Sun Apr  4 08;04;45 comment by...boveia -->
<pre>SB5W6L1 AVDD and DVD returned to their previous state immediately after the shift crew finished dmode calibrations.  the pinky occurred around the time we stopped a physics run and coldstarted the calibrations (then had a L2 w/o L1 SRC error.)</pre>




<!-- Date: Sun Apr 4 11:04:12 2004 -->
<pre>new store was going in, quenched at flattop. Don't know yet if we got hit at all..</pre>
<!-- Author: julia -->
<!-- Comment: Sun Apr  4 11;09;04 comment by...julia -->
<pre>..probably at least 2h of quiet time. Access possible, too. I'm calling David.</pre>

<!-- Comment: Sun Apr  4 11;27;55 comment by...julia -->
<pre>did the post-quench checkout, everything ok, they'll ramp up SI for cosmics now.
David will come in in about 1h.</pre>

<!-- Comment: Sun Apr  4 11;29;19 comment by...julia -->
<pre>had another L2w/o L1 after the coldstart.</pre>

<!-- Comment: Sun Apr  4 11;44;15 comment by...julia -->
<pre>This was actually a pbar kicker prefire again!!</pre>


<!-- Date: Sun Apr 4 12:18:06 2004 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-3758&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-3758  width='300' align='top'></a></td><td>Post-quench checkout BLM FIFOS plots</td></tr></table>
<!-- Author: Ben (mon ace) -->


<!-- Date: Sun Apr 4 12:59:47 2004 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-3759&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-3759  width='300' align='top'></a></td><td>FIFOS BLM plots for 27th Mar 2004 18.44</td></tr></table>
<!-- Author: Ben  -->


<!-- Date: Sun Apr 4 13:01:32 2004 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-3760&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-3760  width='300' align='top'></a></td><td>BLM FIFOS plots for 29th March 2004 19.50</td></tr></table>
<!-- Author: Ben -->


<!-- Date: Sun Apr 4 13:03:28 2004 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-3761&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-3761  width='300' align='top'></a></td><td>BLB FIFOS plots for 1st April 2004 20.33</td></tr></table>
<!-- Author: Ben  -->

<!-- Date: Sun Apr 4 13:59:24 2004 -->
Entered in Silicon database: <ul>
<li>Ladder: IB4W5L0 
<li>problem n: 1163 
<li>Status: needs_observation
<li>Type: Unknown
<li>Action: Monitoring
<li>entered by: dkclark 
<li>description is: There have been little to no errors since 3/15/04. Ran it with svxdaq  and found no problems. Keep an eye on it for a little while longer. 
<li>See <a href="http://www-cdfonline.fnal.gov/internal/usr/lmiller/cgi-bin/newproblemdb/DBreport.pl?detsys=ISL&wedge=B4W5&layer=L0">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Sun Apr 4 14:09:24 2004 -->
Entered in Silicon database: <ul>
<li>Ladder: SB0W3L3 
<li>problem n: 752 
<li>Status: needs_observation
<li>Type: Chip_other
<li>Action: Monitoring
<li>entered by: dkclark 
<li>description is: Hasn't been seen since 3/30/04. Watch it for a little while longer before declaring it fixed. 
<li>See <a href="http://www-cdfonline.fnal.gov/internal/usr/lmiller/cgi-bin/newproblemdb/DBreport.pl?detsys=SVX&wedge=B0W3&layer=L3">report</a></ul>
<!-- Author: Problem DB -->



<!-- Date: Sun Apr 4 14:16:00 2004 -->
To do during next quiet time: 
<p> 
Look at any FE amp Oscillation failures in ISL and see which chips can be recovered by changing ISEL bits from 1111 (currently) to 1110. IB2W1L0 is one, there is at least one other.
<!-- Author: David -->


<!-- Date: Sun Apr 4 15:13:48 2004 -->
<pre> 
DATE     STORE ABORT                          LOSSES @ beginning 
03/28/04 3326  clean                           high and spiky. 
03/29/04 3328  DQ9 trigger lead failure,       OK 
               clean (tbc) abort.  
03/30/04 3335  RF trip, later clean abort.     high, spiky, after tuning ok.    
04/01/04 3337  pbar abort kicker prefire       relatively OK but still close  
               A1,A4,F4. during a wet squeeze  to 20 kHz threshold. 
               as part of a checkout,  
               put in another dose into our  
               BLMs. 
04/02/04 3341  multi house quench SVX rad abort  OK but spiky. 
               (power supply corrector magnet) 
04/03/04 3348  clean abort.                      skyrocketing LOSTP. spikes. 
04/04/04 3350  lost at flattop due to pbar  
               abort kicker prefire,  
               F4 and A1 quenched. 
 
times after shutdown when the BLMs latched: 
03/27/04 1844  
03/29/04 1950  
04/01/04 1446 
04/01/04 2033  
04/02/04 0601 
04/04/04 1053 
 
 
 
 
 
</pre>
<!-- Author: rainer -->


<!-- Date: Sun Apr 4 18:59:38 2004 -->
<h3>Chasing Yobu</h3> 
We came up with a nice plan to chase the L2 without L1 errors in the SRC. 
We  put the whole system through several transitions while taking Cosmics. In the previous cases, L2 wo L1 happened during transitions. Here is our little transitions tour: 
<ol> 
<li> Halt 
<li> Recover 
<li> Run 
<li> End 
<li> Config 
<li> Activate 
<li> End  
<li> Config 
<li> Activate 
<li> Abort 
<li> Config 
<li> Activate 
<li> End 
<li> Config 
<li> Activate 
</ol> 
The SRC never pulled error ... so there have to be several things coming together. Maybe this is rate related ?  
<!-- Author: Marcel, Rainer and the Aces -->


<!-- Date: Mon Apr 5 08:28:38 2004 -->
<b> found LA fired </b> saved in L2W0L1_K.X__  
<!-- Author: rainer -->


<!-- Date: Mon Apr 5 09:20:29 2004 -->
<pre>L2w/oL1 happens after a HRR</pre>
<!-- Author: julia -->


<!-- Date: Mon Apr 5 09:25:04 2004 -->
<pre>another SRC error &lt;a href= 
'http://www-cdfonline.fnal.gov/cgi/elog/elog.pl?nb=2004&action=view&page=210&frame=2&anchor=09:12:37.033'&gt; 
here &lt;/a&gt;, relevant scope trace is L2W0L1_L time stamp 9:09:13 (8:09:13 on the non DST scope) 
likely trigger table related ? 
</pre>
<!-- Author: rainer -->


<!-- Date: Mon Apr 5 10:24:43 2004 -->
Trip in L00 wedges west 0 and 1 about  1003. 
Reset trips and turned individual ladders to stby. 
Wedge 0 channel 0, 1 and 3 needed to tripped on DVDD more than once.  Pausing between turning each ladder to stby seemed to work.  Then turned all ladders to on.  Recovered run once bias voltages were up.  
<!-- Author: ssf -->