<!-- Title: 11:51:03  Mon Jan 16 2006 -->
<!-- Crewchief: JP (MPC-weekday) -->
<!-- Op1: Tuula (MPC-weekend) -->
<!-- Op2: Ankush (SPL on-call) -->
<!-- Op3: &nbsp; -->
<!-- Op4: &nbsp; -->
<!-- Op5: &nbsp; -->
<!-- Op6: &nbsp; -->
<!-- Notes: -->
<p>Tev is down for two weeks due to 14 Jan '06 mega-quench. Silicon is recorving.</p> 
 
<p>Plan: Go over problem ladders. See if they can be fixed.  Use access time to go over low-level PS & ladder problems.</p> 
 
<p>Otherwise, exercise Silicon with Silicon Cosmics Run.</p> 
 
 
  

<!-- Date: Mon Jan 16 13:42:26 2006 -->
Entered in Silicon database: <ul>
<li>Ladder: SB3W7L2 
<li>problem n: 1046 
<li>Status: needs_observation
<li>Type: Chip_capid
<li>Action: Diagnosis_update
<li>entered by: sasha 
<li>description is: CAP_ID error on chip89 re-appeared again right before the quench on 01/14/06. Looking on the history of this error during 150-day period, one can see that it appears and disappears. It looks like rebooting or changing VRB doesn't really help to cure this problem, so the problem is internal.  
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B3W7&layer=L2">report</a></ul>
<!-- Author: Problem DB -->



<!-- Date: Mon Jan 16 14:05:10 2006 -->
<pre>We have gone through several ladders (see list bellow) and decided to with them (or part of them) a try by doing some changings in the HWDB but failed. This is the error that 
is shown after trying to write the changes into the HWDB. 
 
 
Update: <UPDATE CHIPCHAINS SET BITSTREAM='00800080008000800080008000800080162D36 
D0C63F7C380D001000100010001000100010001000D0A2C5169AF8870FA701000200020002000200 
0200020002005AB4D84413FFF0E134004000400040004000400040004000408B16DB68E21F3E9C06 
00080008000800080008000800080068D162234DFCC387D300000100010001000100010001000100 
2D5A6CA5897FF8701A002000200020002000200020002000A0458BCD34F10F1F4E03000400040004 
000400040004000400AC68B11F26FEE1C36900800080008000800080008000800080152D76C4C43F 
7C380D001000100010001000100010001000B0A2C59E98F8870FA701000200020002000200020002 
00020056B4D81513FFF0E134004000400040004000400040004000C08A16FB62E21F3E9C06000800 
08000800080008000800080058D162674CFCC387D3000001000100010001000100010001002B5AEC 
8D897FF8701A' WHERE CARD_CARDNAME='FIB_05' AND FIBCHANNEL=9> 
Error writing BitStream to db, ChipChain FIB_05 9 
java.sql.SQLException: ORA-04098: trigger 'HDWDB_PRD.CHIPCHAINUPDATES0' is inval 
id and failed re-validation 
</pre>
<!-- Author:  Juan Pablo/ Sasha / Ankush -->
<!-- Comment: Mon Jan 16 18;52;47 comment by...Sebastian -->
this is not a surprise (considering the <a href=
'http://www-cdfonline.fnal.gov/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=283&frame=2&anchor=17:57:54'>
problems</a> with traceSilicon), we will have to wait for Bill to look at this.
<!-- Date: Mon Jan 16 14:23:56 2006 -->
<pre>SVX check-up : 
Post-quench check-out after two days 
 
e012 : still no z-side 
e1a4 : CAP_ID in chip 88 (old problem) 
       chips 89,a2 look fine now (CONSIDERED HWDB change 255->9) 
       chip a3 - pedestal has slope(CONSIDERED HWDB change 9->10 
       for threshold) 
[see the figure bellow for latest behaviour of e1a4 on svxdaq as 
 of today] 
e254 : re-included chips 89 -> on (CONSIDERED HWDB change) 
       it runs on svxdaq in RA and NN 
       Seems to have truncated readout when during high lumi 
       when changing the readout length starts giving truncate 
       errors (but other "healthy" ladders do it as well, e253,                  
       e252) 
e414 : sparse out 8b (CONSIDERED HWDB chagnge) 
       89 has capid errors - continue studies (old problems) 
 
 Could not try to change the considered HWDB changes because of 
the above reason.</pre>
<!-- Author: Juan Pablo / Sasha / Ankush -->
<!-- Comment: Tue Jan 17 07;52;13 comment by...Sebastian -->
<table border=0><td><tr><td bgcolor=#e0e030>The DB problems (indeed it was a small typo) have been corrected by Bill B, everything should work now.</td></tr></td></table>
<!-- Comment: Tue Jan 17 19;37;50 comment by...Ankush -->
<p>traceSilicon works again!!!</p>
<!-- Date: Mon Jan 16 14:27:46 2006 -->
<table><tr><td><a href=/elog/notebooks/silicon/Mon_Jan_16_2006_142742.ps align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-8184  align='top'></a></td><td> behaviour of e1a4 in Svxdaq as for today </td></tr></table>
<!-- Author:  Juan Pablo -->

<!-- Date: Mon Jan 16 15:31:18 2006 -->
Entered in Silicon database: <ul>
<li>Ladder: LB1W4L3 
<li>problem n: 1607 
<li>Status: needs_work
<li>Type: Chip_bit_error
<li>Action: Diagnosis_update
<li>entered by: mhartz 
<li>description is: Took a look at this guy during quiet time.  Could not reproduce the errors running with or without the other ladders in the wedge.  Also tried varying the default rdriver from 7 down to 4 and 2, but no luck. Checked svxdaq against chip editor and setting were the same.  The lack of errors may not be suprising since the errors were not in the most recent runs. 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=L00&wedge=B1W4&layer=L3">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Mon Jan 16 15:33:55 2006 -->
Entered in Silicon database: <ul>
<li>Ladder: IB1W0L3 
<li>problem n: 1032 
<li>Status: needs_work
<li>Type: Chip_capid
<li>Action: Diagnosis_update
<li>entered by: mhartz 
<li>description is: Still cannot reproduce these errors in svxdaq.  Compared setting to chip editor and they are the same.  Did notice that the error appears to be in the most recent cosmics run, 210108, so we may be able to use a cosmics run to debug this problem. 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=ISL&wedge=B1W0&layer=L3">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Mon Jan 16 15:36:42 2006 -->
Entered in Silicon database: <ul>
<li>Ladder: IB5W5L2 
<li>problem n: 853 
<li>Status: needs_work
<li>Type: Chip_capid
<li>Action: Diagnosis_update
<li>entered by: mhartz 
<li>description is: Tried (without success) to reproduce the chip 98 capid errors.  Attempts were: running in NN with bulkhead biased and both wedges from fib included, running in NN with bulkhead biased and only f552 included, running in NN with only f552 for 100,000 events to see if onset of stuck capid is low probablility.  All attempts were failures.  This error still appears in data with >90% rate. 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=ISL&wedge=B5W5&layer=L2">report</a></ul>
<!-- Author: Problem DB -->




<!-- Date: Mon Jan 16 19:17:01 2006 -->
<h3>Silicon DMode Calibrations</h3> 
 
<p>By chance a 'beam-off' DMode calibatrion was made just before the quench.  So I've just ordered another DMode calibration. Hopefully a <em>diff</em> of the two calibration runs will show if anything has significantly changed.</p> 
 
<p>The relevant run numbers:  
<ul> 
 <li>Pre-Quench: Friday 13 Jan '06 
  <ul> 
   <li>Run 210031 : DPS ON</li> 
   <li>Run 210032 : DPS OFF</li> 
  </ul> 
 </li> 
 <li>Post-Quench : Monday 16 Jan '06 
   <ul> 
    <li>Run 210197 : DPS ON</li> 
    <li>Run 210198 : DPS OFF</li> 
   </ul> 
 </li> 
</ul> 
 
</p> 
<!-- Author: Ankush -->



<!-- Date: Tue Jan 17 14:14:36 2006 -->
<h3>Supervised access summary (so far)</h3> 
Went down to investigate several ladders: 
<h4>e263</h4> 
Two weeks ago e263 had a <a href= 
'http://www-cdfonline.fnal.gov/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=282&frame=2&anchor=15:35:29'>sudden jump in bias current</a>.  Went down to try a cable swap and cable probe of the bias line.<br> 
Swapped cables with neighboring supply IB1W5, then turned both supplies on.  The high bias current moved to the monitoring channel for e153, which means the problem stayed with the ladder.<br> 
Then we probed the bias line for both e263 and e153 (the two readings correspond to switching the positive and negative leads to the multimeter): 
<ul> 
<li> e263: 
   <ul> 
   <li> positive to negative: 72.4/36.8 kOhms 
   <li> positive to reference: 0.456/0.416 MOhms 
   <li> negative to reference: 0.373/0.496 MOhms 
   </ul> 
<li> e153: 
   <ul> 
   <li> positive to negative: 63.5/40.0 kOhms 
   <li> positive to reference: quick ramp up to OL 
   <li> negative to reference: quick ramp up to OL 
   </ul> 
</ul> 
 
So e263 is NOT consistent with being a healthy ladder. 
 
<h4>e123</h4> 
This ladder also had a sudden jump up in current, although it was far in the past (around DS Day 1600) and hadn't been investigated yet.  We just tried doing a cable probe of the bias line and compared the results to its neighbor e223 (since it's a L3, it's comparable to the ones above as well): 
 
<ul> 
<li> e123: 
   <ul> 
   <li> positive to negative: 95.3/43.0 kOhms 
   <li> positive to reference: 21.3/21.1 kOhms 
   <li> negative to reference: 96.1/41.0 kOhms 
   </ul> 
<li> e153: 
   <ul> 
   <li> positive to negative: 58.6/39.4 kOhms 
   <li> positive to reference: quick ramp up to OL 
   <li> negative to reference: quick ramp up to OL 
   </ul> 
</ul> 
 
Again, the ladder is NOT consistent with healthy. 
 
<h4>f414</h4> 
This one was investigated back in <a href= 
'http://www-cdfonline.fnal.gov/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=269&frame=2&anchor=13:51:05'>October</a> when we saw that it had been reading back 0 current when biased for a while.  At that time, we hooked up a loadbox and confirmed that the supply/crate saw current when loadboxed up.  Today, we went down to swap cables to make sure there was no problem with the ladder.<br> 
We first tried swapping cables with neighboring supply IB4W0... eventually we realized that f404 is the one other ladder that we know the Bias41 readback doesn't work!  So before and after swapping f414 and f404, Bias41 read back 0 current for both of them.<br> 
Then we tried swapping cables with neighbor IB5W5.  This time it worked, and we saw: 
<ul> 
<li> before switch: IB4W1 (cabled to f414) 
   <ul> 
   <li> Bias40: 41.0 V, 93 microA 
   <li> Bias41: 41.1 V, 0 microA 
   </ul> 
<li> IB4W1 (cabled to f554) 
   <ul> 
   <li> Bias40: 41.8 V, 26 microA 
   <li> Bias41: 41.0 V, 0 microA 
   </ul> 
<li> IB5W5 (cabled to f414) 
   <ul> 
   <li> Bias40: 42.0 V, 70 microA 
   <li> Bias41: 48.0 V, 76 microA 
   </ul> 
</ul> 
 
Good news is the ladder looks perfectly fine.  Bad news is we don't really know what's up with this power supply... we previously figured out it couldn't be a power supply or readback problem, because the current reads back fine when it's hooked to a loadbox.  But the current when hooked to the loadbox does seem to be a little low... maybe this channel just had the calibration screwed up, and the current is offset by a lot?<br>
<!-- Author: Jen, Ankush, Juan Pablo -->
<!-- Comment: Tue Jan 17 19;21;56 comment by...Mark, Sasha and Ankush -->
<h3>Access Summary Part 2: Detector Work</h3>

<p>There were 3 ladders which we wanted to examine during the second half of the access:

<ul>
<li>e212: Has low level bit problem</li>
<li>e393: Has had a long history of bit 3 stuck low.  Went in to reinvestigate.</li>
<li>e182: Has low level bit problem</li>
</ul>

<h4>e212</h4>
<p>Upon running with SVXDAQ, this ladder ran error free.  So no need to investigate this ladder.</p>

<h4>e393</h4>
<p>This ladder had a long history of bit 3 problems with many RX swaps. All to no avail.  However we decided we could do better...</p>
<p>We did a fibre swap which indicated the problem was with the detector.  So we did a light-level measurement with the results below.  

<table border="1">
<tr><td>Bit #</td><td>Light</td></tr>
<tr><td>Bit 0</td><td>72 uW</td></tr>
<tr><td>Bit 1</td><td>34 uW</td></tr>
<tr><td>Bit 2</td><td>38 uW</td></tr>
<tr><td>Bit 3</td><td>16 uW</td></tr>
<tr><td>Bit 4</td><td>31 uW</td></tr>
<tr><td>Bit 5</td><td>45 uW</td></tr>
<tr><td>Bit 6</td><td>44 uW</td></tr>
<tr><td>Bit 7</td><td>72 uW</td></tr>
<tr><td>OBDV </td><td>208uW</td></tr>
</table>

You see the light levels are all low, in particular bit 3.  However the errors from this ladder don't look like the classic bit error.</p>

<h4>e182</h4>

<p>This ladder has a low rate of 00 sequence errors with a high rate of illegal channels. A fibre-swap with e181 gives a low rate of 00 sequence errors; 1 after 2,000 events. Whilst the other pipe gave 0 errors. So the error follows the fibre and we proceeded to do a light level measurement for e182.  The results are below:

<table border="1">
<tr><td>Bit #</td><td>Light Level</td></tr>
<tr><td>Bit 0</td><td>840 uW</td></tr>
<tr><td>Bit 1</td><td>1.16 mW</td></tr> 
<tr><td>Bit 2</td><td>980 uW</td></tr>
<tr><td>Bit 3</td><td>620 uW</td></tr>
<tr><td>Bit 4</td><td>506 uW</td></tr>
<tr><td>Bit 5</td><td>1.14 mW</td></tr>
<tr><td>Bit 6</td><td>1.16 mW</td></tr>
<tr><td>Bit 7</td><td>1.00 mW</td></tr>
<tr><td>OBDV</td><td>1.04 mW</td></tr>
</table>

The light from e182 was quite large.  So we were speculating some of the bits may be saturated. So we went on to measure the light from e181

<table border="1">
<tr><td>Bit #</td><td>Light Level</td></tr>
<tr><td>Bit 0</td><td>370 uW</td></tr>
<tr><td>Bit 1</td><td>408 uW</td></tr>
<tr><td>Bit 2</td><td>456 uW</td></tr>
<tr><td>Bit 3</td><td>296 uW</td></tr>
<tr><td>Bit 4</td><td>408 uW</td></tr>
<tr><td>Bit 5</td><td>530 uW</td></tr>
<tr><td>Bit 6</td><td>344 uW</td></tr>
<tr><td>Bit 7</td><td>256 uW</td></tr>
<tr><td>OBDV</td><td>408 uW</td></tr>
</table>

The light from this ladder look fine.</p>
<!-- Date: Tue Jan 17 14:16:27 2006 -->
Entered in Silicon database: <ul>
<li>Ladder: SB1W2L3 
<li>problem n: 683 
<li>Status: needs_longterm_monitoring
<li>Type: BIAS
<li>Action: PS_work
<li>entered by: jpursley 
<li>description is: Probed the bias line cable to investigate why this ladder draws such high current.  Ladder is not consistent with healthy; maybe a pinhole?  See <a href= 'http://www-cdfonline.fnal.gov/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=284&frame=2&anchor=14:14:36'>elog</a> 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B1W2&layer=L3">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Tue Jan 17 14:18:31 2006 -->
Entered in Silicon database: <ul>
<li>Ladder: SB2W6L3 
<li>problem n: 1335 
<li>Status: needs_work
<li>Type: BIAS
<li>Action: PS_work
<li>entered by: jpursley 
<li>description is: Did a cable swap and probed the bias line, confirmed problem is with the ladder and not the power supply.  Ladder is not consistent with healthy (measurable resistances between positive-reference and negative-reference).  See <a href= 'http://www-cdfonline.fnal.gov/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=284&frame=2&anchor=14:14:36'>elog</a> 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B2W6&layer=L3">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Tue Jan 17 14:20:47 2006 -->
Entered in Silicon database: <ul>
<li>Ladder: IB4W1L4 
<li>problem n: 1454 
<li>Status: needs_work
<li>Type: BIAS
<li>Action: PS_work
<li>entered by: jpursley 
<li>description is: Tried a cable swap to check out the ladder.  When cabled to another supply, f414 draws normal current, so it looks like somehow the problem IS with the supply; maybe a large current offset on that channel?  See <a href= 'http://www-cdfonline.fnal.gov/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=284&frame=2&anchor=14:14:36'>elog</a> 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=ISL&wedge=B4W1&layer=L4">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Tue Jan 17 18:44:43 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: mhartz 
<li>description is: Took a look at this to see if the DVDD had returned to normal.  Was able to bring the ladder to standby intially with DVDD current fluctuating around 190 uA (previous nominal was 160 uA), but after a couple of minutes it tripped on DVDD overcurrent and then tripped continuously on DVDD overvoltage.  I have taken it back offline. 
<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: Tue Jan 17 18:50:32 2006 -->
The <a href= 
'http://www-cdfonline.fnal.gov/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=280&frame=2&anchor=20:46:20'> 
problem</a> with the java code of the PSGui was fixed by Dean H. Thanks. I will put everything into cvs (and start the server and java code form the same place..).<br>
<!-- Author: Sebastian -->


<!-- Date: Tue Jan 17 19:32:18 2006 -->
Entered in Silicon database: <ul>
<li>Ladder: SB2W1L2 
<li>problem n: 928 
<li>Status: needs_observation
<li>Type: Chip_bit_error
<li>Action: Diagnosis_update
<li>entered by: amitra 
<li>description is: <p>I ran this ladder in SVXDAQ and it ran error free.  See if it continues to run error free after a week of beam-time.</p> 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B2W1&layer=L2">report</a></ul>
<!-- Author: Problem DB -->



<!-- Date: Tue Jan 17 19:40:39 2006 -->
Entered in Silicon database: <ul>
<li>Ladder: SB3W9L3 
<li>problem n: 1410 
<li>Status: needs_work
<li>Type: Chip_bit_error
<li>Action: Diagnosis_update
<li>entered by: amitra 
<li>description is: <p>We reinvestigated this ladder.  A fibre swap confirmed the error was with the detector.  So we went to measure the light levels. The results are below:  <table border='1'>  <tr><td>Bit #</td><td>Light</td></tr>  <tr><td>Bit 0</td><td>72 uW</td></tr>  <tr><td>Bit 1</td><td>34 uW</td></tr>  <tr><td>Bit 2</td><td>38 uW</td></tr>  <tr><td>Bit 3</td><td>16 uW</td></tr>  <tr><td>Bit 4</td><td>31 uW</td></tr>  <tr><td>Bit 5</td><td>45 uW</td></tr>  <tr><td>Bit 6</td><td>44 uW</td></tr>  <tr><td>Bit 7</td><td>72 uW</td></tr>  <tr><td>OBDV </td><td>208uW</td></tr>  </table>  So Bit 3 looks low.  But the errors from this ladder seem to be more than just Bit 3 low.</p> 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B3W9&layer=L3">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Tue Jan 17 19:45:43 2006 -->
Entered in Silicon database: <ul>
<li>Ladder: SB1W8L2 
<li>problem n: 1469 
<li>Status: needs_work
<li>Type: Chip_bit_error
<li>Action: Diagnosis_update
<li>entered by: amitra 
<li>description is: <p>This ladder was reinvestigated.  A fibre swap showed the problem was with the ladder. So we did a light level measurment.  The results are:  <table border='1'>  <tr><td>Bit #</td><td>Light Level</td></tr>  <tr><td>Bit 0</td><td>840 uW</td></tr>  <tr><td>Bit 1</td><td>1.16 mW</td></tr>  <tr><td>Bit 2</td><td>980 uW</td></tr>  <tr><td>Bit 3</td><td>620 uW</td></tr>  <tr><td>Bit 4</td><td>506 uW</td></tr>  <tr><td>Bit 5</td><td>1.14 mW</td></tr>  <tr><td>Bit 6</td><td>1.16 mW</td></tr>  <tr><td>Bit 7</td><td>1.00 mW</td></tr>  <tr><td>OBDV</td><td>1.04 mW</td></tr>  </table>  The light levels for this ladder are still high. So it could be saturating the RX.  However when we swapped the fibre with a neighbouring pipe on the FTM the error rate did drop. So the problem could be combination of high light levels and a problem with the RX.</p> 
<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: Tue Jan 17 21:21:19 2006 -->
<p><font size=+1> D-mode Calibration Job Started </font>
<p><pre>
Job id            : 428
Calibration type  : standard
Run period tag    : Jan_2006
DPS-off run       : 210032
DPS-on run        : 210031
Requested by      : Jason Nielsen
Main process id   : 18089
</pre>
<!-- Author: CDF silicon D-mode calibration job server v1.4 -->


<!-- Date: Wed Jan 18 01:31:10 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 428 FAILED.

Job info
--------
Calibration type : standard
Beam condition   : off
DPS-off run      : 210032
DPS-on run       : 210031
Requested by     : Jason Nielsen
Submitted        : 2006-01-17 21:20:37
Completed        : 2006-01-18 01:30:50
Status           : FAILURE

Last processing stage reported : updating ped tables with fibkill channels
Failure diagnostics :
child process exited abnormally
</pre>
<!-- Author: D-mode script  -->



<!-- Date: Wed Jan 18 08:54:24 2006 -->
<pre>e3a4 : tripped again 
They are moving the noth wall. So Dervin's theory works. 
Temporarily we get it out of the database ( SVX ifix is 
red now and will always be red if we do not get it out ; we 
prefer to have svx-ifix green just in case a more serious 
thing happens). 
</pre>
<!-- Author:  Ankush, Juan Pablo -->


<!-- Date: Wed Jan 18 09:43:18 2006 -->
<h3>Just got a call from the MCR (!)</h3> 
 
<p>I just got a call from the MCR asking how much damage was received by the Silicon detector.  I told all 4 BLMs saturated and a number of weak ladders have started giving errors.  But overall we were OK.  Certainly much better compared to other mega-quench incidents.  The lady at the other end sound <em>really</em> relieved.</p> 
 
<p>So, as far as I know, this is the first time anyone from the MCR has called asking about the state of the Silicon.  Would any of the ex-SPLs care to comment ?....or are we moving into a new era of friendly cooperation between MCR and CDF Silicon?  I certainly hope so :-)</p>
<!-- Author: A bemused Ankush -->
<!-- Comment: Wed Jan 18 15;16;44 comment by...Only the paranoid survive -->
Coincidentally, something similar happened to me this morning.
Some guy was carelessly swinging a baseball bat around on the sidewalk and smacked me from behind. He asked if I was injured.
I said that my pain sensors saturated and my weak knees have started giving some problems. But overall, I'm ok. 
He sounded really relieved.
<!-- Comment: Wed Jan 18 17;17;02 comment by...Lt. Col. Kilgore -->
You have forgot to add, that you felt much better compared to the CDF truck hitting you on the parking lot.
<!-- Comment: Fri Jan 20 14;44;50 comment by...someone who thought cooperation already existed -->
<pre>Given the incident happened on a weekend, maybe they were just getting a jump on gathering information instead of waiting for the next 9 o'clock meeting, especially since Monday was a holiday.</pre>
<!-- Date: Wed Jan 18 11:41:21 2006 -->
<h4> Important incident </h4> 
We all agree, that Rainer said something very useful today: 
<pre> The BLM is a very useful tool for post mortem analysis  
</pre> 
We are very proud of him
<!-- Author: Dr. Frankenstein -->


<!-- Date: Wed Jan 18 13:17:51 2006 -->
Marcel noticed that some L00 DVDD currents were pink in IMON, a coldstart brought things back to normal. Don't know what caused this.
<!-- Author: Sebastian -->


<!-- Date: Wed Jan 18 15:49:19 2006 -->
Entered in Silicon database: <ul>
<li>Ladder: SB4W1L4 
<li>problem n: 1521 
<li>Status: needs_work
<li>Type: Chip_other
<li>Action: Diagnosis_update
<li>entered by: sasha 
<li>description is: It turns out that chip 8b is already sparsed out in HWDB (svxdaq doesn't pick it up by some reason). 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B4W1&layer=L4">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Wed Jan 18 16:38:59 2006 -->
Entered in Silicon database: <ul>
<li>Ladder: SB2W5L4 
<li>problem n: 1358 
<li>Status: needs_observation
<li>Type: DRO_00F3
<li>Action: Diagnosis_update
<li>entered by: sasha 
<li>description is: We studied this ladder with svxdaq. No errors were observed in RA and NN mode after including all chips (<a href= 'http://www-cdfonline.fnal.gov/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=284&frame=2&anchor=14:23:56'> see e-log </a>). So I included back all chips. Let's how this ladder will perform during cosmics runs during this mini shutdown before making the change permanent.  
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B2W5&layer=L4">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Wed Jan 18 16:46:52 2006 -->
Entered in Silicon database: <ul>
<li>Ladder: SB1W10L4 
<li>problem n: 603 
<li>Status: needs_work
<li>Type: Chip_capid
<li>Action: Diagnosis_update
<li>entered by: sasha 
<li>description is: Chips 89 and a2 look OK now (<a href= 'http://www-cdfonline.fnal.gov/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=284&frame=2&anchor=14:27:46'> see e-log </a> and compare with <a href= 'http://www-cdfonline.fnal.gov/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=267&frame=2&anchor=09:42:57'> this </a>), so I changed the threshold from 255 back to 9 for these chips. Chip a3 has slope in ped distribution, so I also changed the threshold for this chip (9->10) in order to reduce the readout time.  
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B1W10&layer=L4">report</a></ul>
<!-- Author: Problem DB -->



<!-- Date: Wed Jan 18 16:54:20 2006 -->
<center><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-8189&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-8190' ></a><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-8191&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-8192' ></a><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-8185&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-8186' ></a><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-8187&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-8188' ></a></center>
<!-- Author: Mark -->
<!-- Comment: Wed Jan 18 17;03;26 comment by...Sebastian,Retired Busybody,Mark -->
Around 4pm we were informed that L00 had tripped, so we came over to the Control Room and found that a number of L00 wedges and one ISL wedge had tripped on the software protections for high DVDD current.  There were also a lot of pinkies on ladders that had not tripped.  Looking at the DVDD currents, they appeared to be moving around when they should be flat.  This behavior appears in L00, ISL and SVX as can be seen from the plots, so we believe that this is related to a clock glitch.  Since this has already happened today, Sebastian has set up the logic analyzer on the ISL/L00 SRC to look for the next occurence.

<!-- Comment: Wed Jan 18 17;04;57 comment by...Mark/Marcel -->
Also, Marcel and I took a look in the collision hall to make sure there was nothing fishy going on there. We did not see anything suspicious.

<!-- Comment: Wed Jan 18 17;13;00 comment by...Marcel -->
One should also add, that the ISL SRC was in error indicating a GAP end before PA reset. Thisusually indicates a problem with the beam structure delivered by CDF clock. However, if I recall right, if we do not send any Preamp resets, the AVDD starts to decrease. But this time, we only saw an impact on the DVDD. So something else must have happened there. If it happens again, the LA  will catch the necessary information.



<!-- Comment: Wed Jan 18 20;34;00 comment by...s -->
no error this far. I had to disconnect the LA because there is going to be people working on the L3 cluster on the first floor tomorrow early morning. 
<!-- Date: Wed Jan 18 17:46:58 2006 -->
Entered in Silicon database: <ul>
<li>Ladder: SB3W7L2 
<li>problem n: 1046 
<li>Status: needs_work
<li>Type: Chip_capid
<li>Action: Diagnosis_update
<li>entered by: mhartz 
<li>description is: Took a look at this in svxdaq and we can currently reproduce the chip 89 capid errors, so if we want to try messing with the ISEL bits we can. 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B3W7&layer=L2">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Wed Jan 18 17:46:58 2006 -->
Entered in Silicon database: <ul>
<li>Ladder: SB3W7L2 
<li>problem n: 1046 
<li>Status: needs_work
<li>Type: Chip_capid
<li>Action: Diagnosis_update
<li>entered by: mhartz 
<li>description is: Took a look at this in svxdaq and we can currently reproduce the chip 89 capid errors, so if we want to try messing with the ISEL bits we can. 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B3W7&layer=L2">report</a></ul>
<!-- Author: Problem DB -->





<!-- Date: Wed Jan 18 18:12:18 2006 -->
<center><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-8195&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-8195' width='300'></a><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-8197&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-8197' width='300'></a></center>
<!-- Author: Ankush -->
<!-- Comment: Wed Jan 18 18;20;39 comment by...Ankush & Juan Pablo -->
<h3>IV Curves for e123 and e263</h3>

<p>The IV curves for the two ladders which probed yeserday are shown above.  The plot for e123 looks like a 140K-Ohm resistor.  The plot for e263 shows it does deviate from a straight line showing this ladder still has some diode like properties despite the much larger bias current.</p>




<!-- Date: Wed Jan 18 21:17:56 2006 -->
There is a plan to take cosmics with silicon to test silimon but we are having problems with b0xtrp00... 
<!-- Author: Sebastian -->
<!-- Comment: Wed Jan 18 22;10;33 comment by...s -->
b0xtrp00 was a casuality of the file server move.. we are taking data with silicon.

<!-- Date: Thu Jan 19 08:27:09 2006 -->
Entered in Silicon database: <ul>
<li>Ladder: SB2W6L3 
<li>problem n: 1619 
<li>Status: needs_observation
<li>Type: BIAS
<li>Action: IMON_limits
<li>entered by: amitra 
<li>description is: <p>The cable probe confirmed this ladder is not heathly (see thread 1335).  As we now know why the current is so large the upper IMON limit will be bumped up.  However this ladder still needs work which continues in thread 1335.</p>    <table border=1>
<tr><th>IMON LIMITS</th><th>Old</th><th>New</th></tr>
<tr><td><b>Nominal</b></td><td>30.2602</td><td>1284.0</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.0</td><td>1286.0</td></tr></table> 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B2W6&layer=L3">report</a></ul>
<!-- Author: Problem DB -->



<!-- Date: Thu Jan 19 11:53:14 2006 -->
<h3>Accesss to try to fix e182</h3> 
 
<p>From the previous access we noticed the error rate for e182 dropped when we did a fibre swap with e181. So we decided to swap the two RXs with each other.  In RA mode the error rate dropped significantly.  However the illegal channel/00 sequence errors are still present in NN mode.  So we probably have some residual chip problems with this ladder.</p> 
 
<p>For reference, here are the RX for the two ladders: 
 
<ul> 
<li>SB1W8L1 => RX 1107</li> 
<li>SB1W8L2 => RX 1109</li> 
</ul> 
 
</p>
<!-- Author: Ankush, Juan-Pablo, Mark -->

<!-- Date: Thu Jan 19 11:58:21 2006 -->
Entered in Silicon database: <ul>
<li>Ladder: SB1W8L2 
<li>problem n: 1469 
<li>Status: needs_work
<li>Type: RX
<li>Action: Swap_RX
<li>entered by: amitra 
<li>description is: <p>From the previous fibre swap with e181, we noticed the error rate drop significantly.  So we have swapped the 2 RXs.  The error-rate dropped when running in RA mode but are still present in NN mode.  There may be some residual chip problems present.</p>  <p>This ladder now has RX 1109</p><table border=1>
   <tr>
    <td>
     <b>IN:</b>
    </td>
    <td>
     <a href="http://b0sili01.fnal.gov/cgi-bin/rxdb/DBreport.pl?serial=??">??</a>
    </td>
   </tr>
   <tr>
    <td>
     <b>OUT:</b>
    </td>
    <td>
     <a href="http://b0sili01.fnal.gov/cgi-bin/rxdb/DBreport.pl?serial=??">??</a>
    </td>
   </tr>
  </table> 
<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: Thu Jan 19 12:00:13 2006 -->
Entered in Silicon database: <ul>
<li>Ladder: SB1W8L1 
<li>problem n: 1620 
<li>Status: needs_observation
<li>Type: RX
<li>Action: Swap_RX
<li>entered by: amitra 
<li>description is: <p>To fix a problem in SB1W8L2, we swapped the RX for this ladder with SB1W8L2.  Observe the performance of this ladders.  If it runs error free with 1 week of beam time, declare this thread fixed.</p>  <p>The RX in this ladder is: 1107.</p><table border=1>
   <tr>
    <td>
     <b>IN:</b>
    </td>
    <td>
     <a href="http://b0sili01.fnal.gov/cgi-bin/rxdb/DBreport.pl?serial=??">??</a>
    </td>
   </tr>
   <tr>
    <td>
     <b>OUT:</b>
    </td>
    <td>
     <a href="http://b0sili01.fnal.gov/cgi-bin/rxdb/DBreport.pl?serial=??">??</a>
    </td>
   </tr>
  </table> 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B1W8&layer=L1">report</a></ul>
<!-- Author: Problem DB -->



<!-- Date: Thu Jan 19 12:24:02 2006 -->
<center><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-8198&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-8199' ></a><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-8202&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-8203' ></a></center>
<!-- Author: Mark/Juan Pablo -->
<!-- Comment: Thu Jan 19 12;38;54 comment by...Ankush/Juan Pablo/Mark -->
While studying the illegal channel errors that e182 exhibits in NN mode (but not RA) in svxdaq, we tried turning off pedastal subtraction and raising the threshold by the pedastal value while running in NN.  In this way we approximate reading out in NN with dps on, but without actually using dps. As can be seen by the last pulse plots above (dps off is left, dps on is right) this is a fairly good approximation.  With dps off we no longer see the high rate of illegal channel errors.  According to Ankush this behavior has been seen on other ladders which are currently running with dps off and raised thresholds.  We might want to try that with e182 as well.
<!-- Date: Thu Jan 19 12:35:44 2006 -->
<h3>Upgrade of CAEN teststand code (including CPU kernel)</h3> 
 
I flashed the prom of b0sint01 and changed the kernel/startup script. Everything looks fine: I've tried the new gui and server code. I am going to test what will be the default PSgui on b0sint01 and move the gui configuration files and modified the sql scripts that write to the HWDB and the conf files (for svxinter). Then the upgrade/fs move will be over... (I think...).<br>
<!-- Author: Sebastian -->



<!-- Date: Thu Jan 19 16:33:00 2006 -->
<br><b>A509 flash memory</b><br> 
We had an A509 which was sent to CAEN, but when Jen tried 
to test it the mainframe would not see the PS. Since this is similar 
to the problems we had with f03 we tried swapping proms with another supply and it worked! But this prom keeps the calibration 
of the module, so we can not use a different prom on it... so we 
gave the orignal (non-working) prom to Vince, who read it out (had no trouble reading it) and burned the bitstream into a new prom. 
We just tried this new PROM but it also failed (mainframe could not see PS). The next (last?) thing to try is to somehow combine the maps of the good and the bad proms to make one that works. We will talk to Vince about this.
<!-- Author: Jen/Sebastian -->

<!-- Date: Thu Jan 19 17:22:10 2006 -->
Entered in Silicon database: <ul>
<li>Ladder: SB1W3L2 
<li>problem n: 1136 
<li>Status: needs_observation
<li>Type: Chip_bit_error
<li>Action: Diagnosis_update
<li>entered by: sasha 
<li>description is: Bit0 low problem re-appeared again. The error rate sometimes as high as 70%. Needs to be studied during quiet time. We can also try  fiber swap and light level measurement.  
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B1W3&layer=L2">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Thu Jan 19 17:29:11 2006 -->
Entered in Silicon database: <ul>
<li>Ladder: SB2W1L3 
<li>problem n: 65 
<li>Status: needs_observation
<li>Type: Chip_bit_error
<li>Action: Diagnosis_update
<li>entered by: sasha 
<li>description is: Bit5 low problem re-appeared again. Error rate is low, but this ladder is giving errors almost every run. Needs to be re-visited during quiet time. 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B2W1&layer=L3">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Thu Jan 19 17:55:06 2006 -->
Entered in Silicon database: <ul>
<li>Ladder: SB4W1L4 
<li>problem n: 1521 
<li>Status: needs_work
<li>Type: Chip_other
<li>Action: Diagnosis_update
<li>entered by: sasha 
<li>description is: No error since 01/02/06. Continue observations. Need to see how it's going to perform for one or two weeks after a mini shutdown. 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B4W1&layer=L4">report</a></ul>
<!-- Author: Problem DB -->



<!-- Date: Thu Jan 19 18:17:18 2006 -->
<table border=0><td><tr><td bgcolor=#e0e030><pre>Report on New Problematic Ladders. 
 
I went through "Bit Error Rate Monitor" and updated the Problem Database. To avoid duplicating the effor and, thus, waisting of time, the next round can be done 1-2 weeks after the end of mini shutdown.  </pre></td></tr></td></table>
<!-- Author: sasha -->


<!-- Date: Thu Jan 19 18:21:45 2006 -->
While going throug Bit Reporter, I noticed that DS tool doesn't pick up problems with f042. However, this ladder has bit0 high problem every run with error rate of ~3%. Strange...
<!-- Author: sasha -->


<!-- Date: Thu Jan 19 20:37:06 2006 -->
<h2>PSgui/sxvinter code upgrades</h2> 
 
I have finished (hopefully) with the upgrades of svxinter/PSgui: 
<ul> 
<li> The new kernel was flashed some time <a href= 
'http://www-cdfonline.fnal.gov/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=281&frame=2&anchor=22:48:43'> 
ago</a> into svxinter (with some problesm with thertserver) at that moment the server code was upgraded but not the java code 
<li> Dean H fixed the window problem with the java code and I have put the java code and server code into the caencontrol/v4 directory and all into cvs. The server and java codes are working. 
<li> I have moved the PSgui configuration files (CAENvolts.dat, CAENLVcurrents.dat, etc) to <b>/cdf/onln/data/svxii/caencontrol/PSfiles</b>, this is the 
new area for these files (not in the code area anymore!). I have changed the sql scripts (used by traceSilicon) to write to this area now (and tested it).  
<li> Changed the boot parameters in svxinter and the configuration files according to the above changes (had to  
mount the b0spool:/vol/data directory from svxinter - thanks to Frank and Bill for their help). 
<li> Tested everything with e522 (it hold at <b>DVDD of 70mA</b>, but tripped when tried to get data), I am taking it out of the DB again... 
<li> I have updated the instructions to restart the PSgui. 
</ul> 
Let me know of any problems with the PSgui/svxinter/DB tools. 
<br>
<!-- Author: Sebastian -->
<!-- Comment: Thu Jan 19 20;59;50 comment by...Ankush -->
<pre>Well Done Sebastian :-) !!!
I know you've been working hard on this.

....unfortunately this now makes you the PS-Gui/svxinter guru 

as they say, no good deed goes unpunished ;-)</pre>

<!-- Comment: Thu Jan 19 21;07;10 comment by...a/s -->
Ankush just noticed that the new PSgui has the alignment of the status subwindow screwed up. Probably Dean can fix this soon...

<!-- Comment: Thu Jan 19 21;24;33 comment by...ankush/sebastian -->
<h3>How to move to the old PSgui</h3>
Ankush had the good idea of checking if the old gui works, it does:
<ul>
<li> cd /cdf/onln/data/vxworks/svx/daq/PSanywhere.old/ 
<li> source startme
<li> PS
</ul>
That'll get you the old PSgui.



<!-- Comment: Fri Jan 20 11;33;38 comment by...Sebastian  -->
The log files were not accessible through the web. I changed the links and locations of the log files; now in:
http://www-cdfonline.fnal.gov/svx/data1/datalog/PSGUI/ who will
find two directories: log.old/ and log/, the first one has the old psgui log files (located at /cdf/onln/data/vxworks/svx/daq/PSanywhere.old/log) and the log/ link will point you to the recent log files
(<b>/cdf/onln/data/svxii/caencontrol/PSfiles/log</b>). 
Also, the "old-old" files are still at /cdf/onln/home/svxii/daq/PSanywhere/log), all clear, right?
<!-- Comment: Fri Jan 20 18;20;55 comment by...sebastian -->
talk to Dean and showed him the Gui column alignment problem, he will try to fix it...
<!-- Comment: Sun Jan 22 15;21;50 comment by...sebastian -->
turned a wedge on just to check the log files, all looks fine to me.
<!-- Date: Thu Jan 19 21:39:55 2006 -->
While looking for problems of Stage0 Bill and I found that SvxDaqMods has some b0dap hardwire into the code. <b>This will break when the transition to the SL machines is made</b> (right now SVXMon runs on the RH7.3 machines).
<!-- Author: Sebastian -->
<!-- Comment: Fri Jan 20 10;29;43 comment by...Sebastian -->
Also Kaori just pointed me to this problem of SVXMon in the new are:
<pre>
SVXMon 

tried 6.1.2m. in cosmic 
switched tcl.... 

 field is  NON-UNIFORM  
Tcl file: from release. 
Directory /cdf/svx/data1/svxmon/RunArea is not writable 
AC++>  
---- 

will go back to RH.  6.1.2n
</pre>
Mark, did you commited your latest changes to SvxDaqMods to cvs?
<!-- Date: Fri Jan 20 08:30:08 2006 -->
<h3>Overnight Silicon COSMICS running</h3> 
 
<p>With much arm twisting from Rick we had an overnight COSMICS runnning with Silicon.  The run number is: 210392 which ran for ~5.5 hours.  There were no problems except for some reason they paged Sebastian (?????).  Fortunatly Sebastian didn't get the page. So he got some sleep.</p> 
 
<p>Now we just need to volunteer someone to analyse data. I volunteer Rick ;-) </p> 
 
<p>...and in future I should not use my angry voice with Jennifer :-)...unfortunatly I was in my automatic "attack ACE" mode.  Jennifer :-) kindly remminded she is no ordinary ACE.  So apologies to Jennifer :-) </p>
<!-- Author: Ankush & Juan-Pablo -->
<!-- Comment: Sat Jan 21 02;48;41 comment by...Jennifer :-) -->
<pre>Many thanks :-)</pre>
<!-- Date: Fri Jan 20 09:07:15 2006 -->
<pre> 
<font size=+2.5>At the 8oclock meeting we have been reminded to  
 
return our supervised access keys by lunch (the timeline is  
16:00).</font> 
</pre>
<!-- Author: Juan Pablo -->

<!-- Date: Fri Jan 20 09:37:31 2006 -->
<p><font size=+1> D-mode Calibration Job Started </font>
<p><pre>
Job id            : 429
Calibration type  : standard
Run period tag    : Jan_2006
DPS-off run       : 210198
DPS-on run        : 210197
Requested by      : Jason Nielsen
Main process id   : 17351
</pre>
<!-- Author: CDF silicon D-mode calibration job server v1.4 -->




<!-- Date: Fri Jan 20 10:37:48 2006 -->
<h3>Tev Dates</h3> 
 
<p>Here are some impotant Tev dates</p> 
 
<ul> 
<li>Tev expected to be cold by 24 Jan; so expect beam on 25/26 Jan.</li> 
<li>Shutdown start: Monday 27 Feb '06</li> 
<li>Shutdown end: ~ Friday 2 June '06</li> 
</ul>
<!-- Author: Ankush -->



<!-- Date: Fri Jan 20 12:14:51 2006 -->
umounted and removed from the automount file the code-common area from the b0dasvx0X machines. Let's see if this time it works.<br>
<!-- Author: Sebastian -->

<!-- Date: Fri Jan 20 14:13:15 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 429 finished successfully.

Job info
--------
Calibration type : standard
Beam condition   : off
DPS-off run      : 210198
DPS-on run       : 210197
Requested by     : Jason Nielsen
Submitted        : 2006-01-20 09:36:34
Completed        : 2006-01-20 14:12:55
Status           : SUCCESS
</pre>
<!-- Author: D-mode script run_calib_analysis.tcl -->





<!-- Date: Fri Jan 20 23:26:55 2006 -->
<pre>One SVX ladder tripped. Silicon is not used  for anything, so it is a bit strange that it tripped. I asked the monitoring ACE to recover the trip and perform coldstart.</pre>
<!-- Author: Tuula -->
<!-- Comment: Fri Jan 20 23;57;23 comment by...Ankush -->
<pre>I tried to look in the PS-Gui log to find out which ladder tripped and what it tripped on.  However the last log file entry was from yesterday at 21:17.  Here is the last entry:

--== GUI Startup Complete ==--
Thu Jan 19 21:17:19 CST 2006     Established communication with iFix
Thu Jan 19 21:17:19 CST 2006     Interlock is enabled

smells like more FS problems......</pre>

<!-- Comment: Sat Jan 21 00;04;05 comment by...Ankush -->
Sorry, ignore my previous comment.  Ankush can't read entries in the e-log.  Sebastian wrote careful instructions on where to get the log files.  

<!-- Comment: Sat Jan 21 00;16;34 comment by...Ankush -->
<p>After reading the instructions, we find out e291 tripped on software protection limit.  This is strange.  However going through the shift e-log entries, two techs from the BD enter the collision hall around the same time the trip occurs. Is this related ?.</p>

<pre>
Fri Jan 20 23:10:53 CST 2006     Software protection trip: High DVDD Current  SV
X B2 W9 L1 current 155.0 softLimit 150.0
Fri Jan 20 23:11:30 CST 2006     ALARM:   SVX  B2  W9 PC is reported OFF, but lo
w/high voltage is above 2/5 V
Fri Jan 20 23:23:40 CST 2006     success: Resetting trips
Fri Jan 20 23:25:04 CST 2006     success: Power Supply SVX B2 W9 ON
Fri Jan 20 23:25:25 CST 2006     success: Power Supply SVX B2 W9 to STANDBY
</pre>

<p>One point:  During the ACE talk we told the ACES to recover trips by power-cycling the whole wedge from OFF to ON.  However in these circumstances (ie:- no beam) we should tak them through only putting the ladder to OFF and then to STANDBY.</p>



<!-- Comment: Mon Jan 23 08;25;23 comment by...Ankush -->
<p>Just looking at the problem database, e291 is the ladder which developed the very large DVDD currents after the previous mini-shutdown before christmas.  So no surprise this ladder tripped on high-DVDD current.  The software protection limit is at 150.0mA and tripped as DVDD current went to 155.0mA.</p>*
<!-- Date: Sat Jan 21 06:00:04 2006 -->
<pre>I will be traveling to O'Hare this morning (9AM-ish) and am currently carrying both the RadMon and Cooling pagers. Please also note the change in my cell phone number: 585.355.9998</pre>
<!-- Author: Jennifer :-) -->


<!-- Date: Sun Jan 22 17:40:38 2006 -->
<h3>CCC interrupts</h3> 
Since the plan is that the CCC is going to issue interrupts 
when it changes clock modes (so that RC knows what is going on), 
I have check that the vector space in the b0svx CPUs is free. The only vectors taken are: 
<pre> 
 4  (0x4): 0x7bfff88 
 7  (0x7): 0x7bfff70 
16 (0x10): 0x7bfffe8 
18 (0x12): 0x7bf47d8 
21 (0x15): 0x7bfffd0 
24 (0x18): 0x7bfffa0 
</pre> 
which are probably used by the system(?). So there is plenty of room.<br> 
<!-- Author: Sebastian -->



<!-- Date: Mon Jan 23 08:29:23 2006 -->
<pre>Silicon bias scan (noise) is in progress.  Event builder problems delayed the startup by about 30 min.  Also, the PS CAENvolts.dat files are no longer on the common code disk (which is mounted read only.)  The new location is /cdf/onln/data/svxii/caencontrol/PSfiles. 
 
run 210523 
CAENvolts_01182006_0856AM.dat 
</pre>
<!-- Author: boveia -->
<!-- Comment: Mon Jan 23 10;53;26 comment by...boveia -->
<pre>Vbias run iev fev lum
-130 210523 0 1018 1536
-90 210523 1019 2014 1536
-80 210523 2015 3006 1536
-70 210523 3007 4080 1536
-60 210523 4081 5104 1536
-50 210523 5105 6073 1536
-40 210523 6074 7069 1536
-30 210523 7070 8680 1536
-20 210523 8681 10152 1536
-10 210523 10153 11375 1536
0 210523 11376 12328 1536
-100 210523 12329 14277 1536
-65 210523 14278 16697 1536
-55 210523 16698 18212 1536
-45 210523 18213 20438 1536
-35 210523 20439 23826 1536
-25 210523 23827 25765 1536
-15 210523 25766 27289 1536
</pre>
<!-- Date: Mon Jan 23 08:36:37 2006 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-8204&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-8204  width='300' align='top'></a></td><td> </td></tr></table>
<!-- Author:   -->
<!-- Comment: Mon Jan 23 08;50;18 comment by...Ankush -->
<h3>DVDD Current history for e291</h3>

<p>On Friday night this ladder tripped on software protection trip for high DVDD current.  The limit is the red line.  So this ladder must have spent some time above 150.0mA and so the trip fired.  If this happens again, we may need to bump up the software protection limit for this ladder.  But we should definintly replace the power supply during the long shutdown.</p>


<!-- Date: Mon Jan 23 09:05:40 2006 -->
<pre>Week summary: 
 
Monday: 
  -DB problems solved 
  -Quiet time studies 
 
Tuesday: 
  -Access: 
     e263-cable swap and cable probe of the bias line 
     e123-cable probe of the bias line 
     f414-cable swap 
     e393-fibre swap and light level measurement 
     e182-fibre swap and light level measurement 
  -java code of the PSGui fixed 
  -D-mode calibration 
 
Wednesday: 
  -e3a4 tripped 
  -some pinkies in L00 DVDD currents 
  -number of L00 wedges and one ISL wedge tripped on software 
   protections for high DVDD current 
  -took cosmics with Silicon 
 
Thursday: 
  -swapped RXs between e182 and e181 
  -upgrade of CAEN teststand code 
  -problem database updated 
  -PSgui/sxvinter code upgrades 
  -took cosmics overnight with Silicon 
 
Friday: 
  -D-mode calibration 
  -e291 tripped on software protection limit 
 
Saturday: 
  nothing 
 
Sunday: 
  -checked the vector space in the b0svx CPUs is free 
 
   </pre>
<!-- Author: Tuula -->