<!-- Title: 11:29:24  Mon Jan 15 2007 -->
<!-- Crewchief: Satyajit -->
<!-- Op1: Ulrich (SPL) -->
<!-- Op2: &nbsp; -->
<!-- Op3: &nbsp; -->
<!-- Op4: &nbsp; -->
<!-- Op5: &nbsp; -->
<!-- Op6: &nbsp; -->
<!-- Notes: -->
<pre>Keep taking data. Expect smooth sailing..</pre>


<!-- Date: Mon Jan 15 11:57:23 2007 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-10621&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-10621  width='300' align='top'></a></td><td>Another channel with strange behavior, see <a href= 
'http://www-cdfonline.fnal.gov/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=335&frame=2&anchor=17:32:48'> 
main e-log</a>. The channel is currently in IGNORE, but we should keep an eye on it.</td></tr></table>
<!-- Author: Ulrich -->


<!-- Date: Mon Jan 15 16:37:05 2007 -->
<h3>Signal-to-Bias Scan for L00</h3> 
 
We have performed a bias scan during the end of the store 5177. Run number  
was <a href="http://www-cdfonline.fnal.gov/java/cdfdb/servlet/RunSummary?RUN_NUMBER=232090">232090</a>. 
The CAENvolts file was /cdf/onln/data/svxii/caencontrol/PSfiles/caenvoltsfiles/CAENvolts_01132007_0537PM.dat 
and we changed the following nominal voltages: 
<br> 
<ul>LB1W1L0, LB1W1L1 and LB1W1L2 to 135 Volts (from 85) 
</ul> 
For the run the following trigger prescales were modified: 
<ul><li><pre> L1_TEN_TRK2_PS250 bit 35   set to 1 (from 250)</pre> </li> 
    <li><pre> L1_TWO_TRK2_PS20K bit 55   set to 50 (from 20K)</pre></li> 
    <li><pre> L2_TWO_CMU1.5_PT1.5_DPHI120_OPPQ_DPS bit 137     set to 1 (from 50)</pre></li> 
    <li><pre> L2_TWO_CMU1.5_PT2_DPHI120_OPPQ_PS50 bit 138      set to 1 (from 50)</pre></li> 
    <li><pre> L2_TRK8_PS100_L1_CMUP6_PT4 bit 135               set to 1 (from 100)</pre></li> 
    <li><pre> L2_TRK2_D120_&_CEM4_PT4_CES3_2DPHI90_DPS bit 132 set to 1 (from 50)</pre></li> 
    <li><pre> L2_PS50_L1_TWO_TRK2   bit 108                    set to 10 (from 50)</pre></li> 
    <li><pre> L2_PS200_L1_TWO_CMU1.5_PT1.5   bit 101           set to 1 (from 200)</pre></li> 
    <li><pre> L2_PS200_L1_CMX6_PT8_CSX   bit 100               set to 1 (from 200)</pre></li> 
    <li><pre> L2_PS0_L1_TEN_TRK2   bit 92                      set to 1 (from 200)</pre></li> 
</ul> 
 
 
The values of the relative voltages for the event number were the following: 
 
<ul><pre> 
 
VOLTAGE       EVENT RANGE      START TIME 
0             0-59811           14:00 
-130          59812-90382       14:06 
-110          90383-126037      14:10 
-90           126038-157090     14:14 
-70           157091-189159     14:18 
-50           189160-219933     14:22 
-30           219934-249382     14:26  
-10           249383-285144     14:30 
0             285145-315241     14:34 
-120          315242-346124     14:44 
-100          346125-377857     14:48 
-95           377858-409105     14:52 
-90           409106-441123     14:56 
-85           441124-470848     14:59 
-80           470846-501267     15:02 
-75           501268-532471     15:07 
-65           532472-563908     15:11 
-60           563909-594309     15:15 
-55           594310-623984     15:18 
-45           623985-655191     15:22 
-40           655192-685568     15:26 
-35           685569-716918     15:31 
-25           716919-747700     15:35 
-20           747701-778044     15:39 
-15           778045-807201     15:43 
-5            807202-838443     15:47 
0             838444-867916     15:51-15:54 
 
</ul></pre>
<!-- Author: Oscar, Roberto & Ulrich -->


<!-- Date: Mon Jan 15 17:20:27 2007 -->
Pink cell: IB0W2L0 in DVDD was followed by an espontaneous trip in the whole wedge (software protection trip). 
We put it back to STAND-BY by hand and seems fine.
<!-- Author: Oscar -->


<!-- Date: Mon Jan 15 18:02:33 2007 -->
Before starting the bias scan, we also had the difficulty that the system thought SVX B1 was still in ON, although everything was off. We were unsuccessful in rebooting SVXINTER and restarting the PS GUI. We then switched the entire bulkhead off and back to STANDBY, which somehow fixed the problem. Now the bias scan is ongoing.
<!-- Author: Ulrich -->


<!-- Date: Mon Jan 15 19:02:47 2007 -->
I produced another update of PSMon.exe, the software that controls (among other things) the AutoHocker. Now the crate, date, and time of the last Hockerization is written into the iFix DB on SVXIICON under the tag name SVX_LAST_HOCKERIZATION. This information is also shown on the iFix Hockerization page.
<!-- Author: Ulrich -->


<!-- Date: Mon Jan 15 19:51:13 2007 -->
<center><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-10622&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-10622' width='300'></a><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-10623&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-10623' width='300'></a></center>
<!-- Author: Oscar & Roberto -->
<!-- Comment: Mon Jan 15 19;53;49 comment by...Oscar/Roberto -->
During the noise-to-bias scan, a couple of pinkies appear. SB0W5L2 shows the typical behaviour: DVDD gets pretty high and AVDD shows variations correlated to the HRR needed in the scan.
We tried to power-cycle the ladder but it did not help.

<!-- Comment: Mon Jan 15 20;21;54 comment by...Ulrich, Oscar & Roberto -->
Values were back to normal until doing a COLDSTART.


<!-- Date: Mon Jan 15 20:23:37 2007 -->
<h3>Noise-to-bias scan for the whole detector</h3> 
 
We took some data for studying the noise-to-bias of the silicon ladders 
in some quiet time between stores,<br> 
The CAENvolts file is /cdf/onln/data/svxii/caencontrol/PSfiles/caenvoltsfiles/C\ 
AENvolts_01132007_0537PM.dat and we had to take two runs due to problems with EVB. Runs were 
<a href="http://www-cdfonline.fnal.gov/java/cdfdb/servlet/RunSummary?RUN_NUMBER\ 
=232127">232127</a> and 
<a href="http://www-cdfonline.fnal.gov/java/cdfdb/servlet/RunSummary?RUN_NUMBER\ 
=232134">232134</a>. 
<br><br> 
The event ranges for the different relative voltages: 
 
<ul><pre> 
  VOLTAGE   RUN      EVENT RANGE   START TIME 
    0      232127       0-1023       17:50 
  -130               1024-2009       17:54 
  -110               2010-2965       18:02 
  -90                2966-3959         X 
  -70      232134       0-962        18:19 
  -50                 963-1934       18:22 
  -30                1935-2964       18:26 
  -10                2965-3948       18:32 
    0                3949-5044       18:37 
  -100               5336-6190       18:47 
  -80                6191-7044       18:53 
  -65                7045-8037       18:56 
  -55                8038-9013       19:03 
  -45                9014-10018      19:08 
  -40               10019-11029      19:12 
  -35               11030-12023      19:19 
  -25               12024-12989      19:22 
  -20               12990-14010      19:27 
  -15               14011-15021      19:32 
  -5                15022-16017      19:37 
  -3                16018-17013      19:43 
</pre></ul>  
<!-- Author: Oscar & Roberto -->

<!-- Date: Tue Jan 16 00:38:50 2007 -->
Entered in Incident database: <ul>
<li>Submitted by: husemann
<li>Description of Problem: At the beginning of this store, b0fib04 would refuse to go through CONFIG. We tried first to reboot the crate, then to reset the crate, without success. Checking the error log we saw that SVX B3W0L1 was the offender. We drove in and power-cycled the corresponding wedge - still no success. In the end we masked the init readback in the hardware database, and finally b0fib04 passed CONFIG. We are now running with Silicon, and as far as we can tell from the raw data and SVXMon, the ladder is returning good data. This is the second masked init readback in a week.
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/idb/DBentry.pl?incident_number=103">Incident Report</a></ul>
<!-- Author: Incident DB -->



<!-- Date: Tue Jan 16 00:42:21 2007 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-10626&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-10627  width='300' align='top'></a></td><td><h3>Store 5179. Init lumi. 211e30</h3> 
There was a problem with b0fib04 going through CONFIG. The 
problem turned out to be in a faulty init readback. Initially 
a Run w/o silicon was started. Silicon was integrated after 
masking the affected readback off.</td></tr></table>
<!-- Author: Satyajit -->
<!-- Comment: Tue Jan 16 00;44;56 comment by...Satyajit -->
<pre>Thanks to Ulrich for giving up his movie and driving-in ahead of
me!</pre>

<!-- Date: Tue Jan 16 00:51:17 2007 -->
Entered in Incident database: <ul>
<li>Submitted by: husemann
<li>Description of Problem: When the Silicon was ramped up, crate 5 decided to lose communication. The AutoHocker took care of it.
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/idb/DBentry.pl?incident_number=104">Incident Report</a></ul>
<!-- Author: Incident DB -->


<!-- Date: Tue Jan 16 00:54:16 2007 -->
Entered in Incident database: <ul>
<li>Submitted by: husemann
<li>Description of Problem: While I was writing up the other hockerization, there was a new one, this time crate #3. The AutoHocker did its job.
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/idb/DBentry.pl?incident_number=105">Incident Report</a></ul>
<!-- Author: Incident DB -->



<!-- Date: Tue Jan 16 08:23:01 2007 -->
The Store 5179 broke live lumi. record per shift but ended  
prematurely around 7:50 am with a <b>quench</b>. The 
<a href= 
'/cgi/elog/elog.pl?nb=2007&action=view&page=46&frame=2&anchor=07:49:10.829'> 
post-quench checkout</a> was OK. 
 
<!-- Author: Satyajit -->
<!-- Comment: Tue Jan 16 10;26;16 comment by...ronmoore -->
No quench, just an abort caused by a failed main bus power supply @ A2.
<!-- Date: Tue Jan 16 08:30:41 2007 -->
<h3>Store Lost - Chiller Swap</h3> 
The Tevatron lost the store around 7:45 this morning. The abort was clean for us, see the <a href= 
'http://www-cdfonline.fnal.gov/cgi/elog/elog.pl?nb=2007&action=view&page=46&frame=2&anchor=07:49:10.829'>main e-log</a>. While they are still investigating, we are currently switch off the Silicon to go back to the default ISL chiller. We will also try to test the assumption that the freeze protection has tripped off the SVX chiller compressor lately.
<!-- Author: Satyajit & Ulrich -->
<!-- Comment: Tue Jan 16 09;05;32 comment by...Satyajit & Ulrich -->
<pre>We are done swapping the chiller. Now bringing silicon to standby.
</pre>

<!-- Comment: Tue Jan 16 11;50;46 comment by...Ulrich -->
<h4>Thoughts on Freeze Protection</h4>
I have also done a test with the SVX chiller's freeze protection mechanism.  While the entire Silicon was off, I regulated the protection to above -10&deg; At around -8&deg;C, the whole chiller (main power, pump, and compressor) tripped off. When I regulated it back to -12&deg;C, the chiller switched on again automatically. Next I went upstairs to check the FTTrend plot of the compressor status. The plot shows that it tripped off. But in the iFix alarm log file, there was no entry about the SVX chiller during the period in question. Probably, the glitch I induced was too short.
<p>
The above observations are all compatible with our conjecture that the reason for the trips is the freeze protection system. We will lower the protection a tiny bit to get further away from a trip (the 70:30 water  - ethylene glycol mixture should be good until -14&deg;C) and also add the other two chiller status variables on the FTTrend plot.
<!-- Comment: Tue Jan 16 15;42;01 comment by...Ulrich -->
The chiller swap made the situation of the compromised cooling line even worse. Now the output temperature is 21.2&deg;C (was around 18&deg;C before), with all four ladders on the cooling line excluded. The high temperature is mainly driven by the high temperature on the supply line of more than 15&deg;C. What can be done? "Massaging" cooling lines had a success rate of way below 50%. It seems that the most efficient measure was the rate-of-rise test. We should look into doing another one of those soon.
<!-- Comment: Wed Jan 17 14;23;12 comment by...Ulrich -->
<p>
I Just realized today that we forgot to unplug the power cord of the backup chiller backup pump and go back to the ISL chiller backup pump. That should be part of the procedures! Done.
<!-- Date: Tue Jan 16 10:08:31 2007 -->
Entered in Silicon database: <ul>
<li>Ladder: SB3W0L1 
<li>problem n: 1878 
<li>Status: needs_observation
<li>Type: Chip_other
<li>Action: Init_RB_mask
<li>entered by: husemann 
<li>description is: b0fib04 was consistently failing CONFIG, so we decided to mask the init readback for e301. After that everything was fine, and the data from that ladder looked ok. 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B3W0&layer=L1">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Tue Jan 16 10:14:16 2007 -->
Entered in Silicon database: <ul>
<li>Ladder: SB0W5L2 
<li>problem n: 1879 
<li>Status: needs_observation
<li>Type: No_Init
<li>Action: Init_RB_mask
<li>entered by: husemann 
<li>description is: Last week this ladder started to have problems initializing occasionally, so we decided to mask the init readback. 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B0W5&layer=L2">report</a></ul>
<!-- Author: Problem DB -->




<!-- Date: Tue Jan 16 14:52:47 2007 -->
Entered in Silicon database: <ul>
<li>Ladder: IB5W2L4 
<li>problem n: 1751 
<li>Status: fixed
<li>Type: BIAS
<li>Action: IMON_limits
<li>entered by: satyajit 
<li>description is: Increasing the upper limit for BIAS0.<table border=1>
<tr><th>IMON LIMITS</th><th>Old</th><th>New</th></tr>
<tr><td><b>Nominal</b></td><td>987.281</td><td>1010.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>1020.0</td><td>1040.0</td></tr></table> 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=ISL&wedge=B5W2&layer=L4">report</a></ul>
<!-- Author: Problem DB -->



<!-- Date: Tue Jan 16 14:58:39 2007 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-10628&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-10629  width='300' align='top'></a></td><td><h3>Store 5182 Init. Lumi. 192e30</h3> 
Silicon was integrated from the start. SVXMon and SVTSpyMon 
plots look fine.</td></tr></table>
<!-- Author: Satyajit -->


<!-- Date: Tue Jan 16 15:03:00 2007 -->
There were a few bias pinkies right after powering up the detectors. Bumped up the bias0 upper limit on f524.
<!-- Author: Satyajit, Jose -->



<!-- Date: Tue Jan 16 20:59:10 2007 -->
SVX resonance around 20:24. Logic analyzer re-armed. Seems that Mark's new logic works, no false positives so far.
<!-- Author: Ulrich -->
<!-- Comment: Wed Jan 17 08;20;48 comment by...Ulrich -->
Another resonance at 5:25. LA re-armed.

<!-- Date: Wed Jan 17 08:56:05 2007 -->
Entered in Silicon database: <ul>
<li>Ladder: SB5W11L1 
<li>problem n: 1880 
<li>Status: fixed
<li>Type: BIAS
<li>Action: IMON_limits
<li>entered by: satyajit 
<li>description is: Bumping up its upper limit for the first time!<table border=1>
<tr><th>IMON LIMITS</th><th>Old</th><th>New</th></tr>
<tr><td><b>Nominal</b></td><td>52.7268</td><td>100.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>120.0</td></tr></table> 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B5W11&layer=L1">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Wed Jan 17 09:02:18 2007 -->
Entered in Silicon database: <ul>
<li>Ladder: SB4W9L4 
<li>problem n: 1881 
<li>Status: fixed
<li>Type: BIAS
<li>Action: IMON_limits
<li>entered by: satyajit 
<li>description is: Bumping up upper limit.<table border=1>
<tr><th>IMON LIMITS</th><th>Old</th><th>New</th></tr>
<tr><td><b>Nominal</b></td><td>99.3</td><td>110.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>118.0</td><td>130.0</td></tr></table> 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B4W9&layer=L4">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Wed Jan 17 09:08:34 2007 -->
Entered in Silicon database: <ul>
<li>Ladder: SB3W7L2 
<li>problem n: 1882 
<li>Status: fixed
<li>Type: BIAS
<li>Action: IMON_limits
<li>entered by: satyajit 
<li>description is: Bumping up upper limit.<table border=1>
<tr><th>IMON LIMITS</th><th>Old</th><th>New</th></tr>
<tr><td><b>Nominal</b></td><td>46.3492</td><td>90.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>110.0</td></tr></table> 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B3W7&layer=L2">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Wed Jan 17 09:14:37 2007 -->
Entered in Silicon database: <ul>
<li>Ladder: SB2W11L1 
<li>problem n: 1883 
<li>Status: fixed
<li>Type: BIAS
<li>Action: IMON_limits
<li>entered by: satyajit 
<li>description is: Bumping up upper limit.<table border=1>
<tr><th>IMON LIMITS</th><th>Old</th><th>New</th></tr>
<tr><td><b>Nominal</b></td><td>48.0288</td><td>100.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>120.0</td></tr></table> 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B2W11&layer=L1">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Wed Jan 17 09:20:59 2007 -->
Entered in Silicon database: <ul>
<li>Ladder: SB2W9L0 
<li>problem n: 1884 
<li>Status: fixed
<li>Type: BIAS
<li>Action: IMON_limits
<li>entered by: satyajit 
<li>description is: Bumping up upper limit.<table border=1>
<tr><th>IMON LIMITS</th><th>Old</th><th>New</th></tr>
<tr><td><b>Nominal</b></td><td>47.4143</td><td>100.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>120.0</td></tr></table> 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B2W9&layer=L0">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Wed Jan 17 09:29:53 2007 -->
Entered in Silicon database: <ul>
<li>Ladder: IB0W3L2 
<li>problem n: 717 
<li>Status: fixed
<li>Type: BIAS
<li>Action: IMON_limits
<li>entered by: satyajit 
<li>description is: The current is just above 470 uA. Bumping up upper limit.<table border=1>
<tr><th>IMON LIMITS</th><th>Old</th><th>New</th></tr>
<tr><td><b>Nominal</b></td><td>65.3125</td><td>450.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>470.0</td><td>490.0</td></tr></table> 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=ISL&wedge=B0W3&layer=L2">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Wed Jan 17 09:40:42 2007 -->
Entered in Silicon database: <ul>
<li>Ladder: IB0W0L1 
<li>problem n: 1741 
<li>Status: fixed
<li>Type: BIAS
<li>Action: IMON_limits
<li>entered by: satyajit 
<li>description is: The Bias0 current is at its limit. Bumpung it up as a precautionary measure.<table border=1>
<tr><th>IMON LIMITS</th><th>Old</th><th>New</th></tr>
<tr><td><b>Nominal</b></td><td>57.4245</td><td>100.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>120.0</td></tr></table> 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=ISL&wedge=B0W0&layer=L1">report</a></ul>
<!-- Author: Problem DB -->



<!-- Date: Wed Jan 17 11:31:03 2007 -->
<h3>Weird ISL/L00 alarm and trigger inhibit</h3> 
Today the shift crew noted a ISL/L00 alarm and got a trigger inhibit for CAEN crate #4. Also IMON popped up a yellow window with "Hockerization may be in progress". The situation cleared itself within seconds, and the AutoHocker didn't kick in. On the other hand, the glitch was seen in SVXINTER, PSMon.exe, and IMON at the same time. SVXINTER says: 
<pre> 
WED JAN 17 10:54:49 2007  Caenet_buffer: Error number 7 7 received 
group_info:cr_n = 4, response = 7 
</pre>
<!-- Author: Ulrich -->


<!-- Date: Wed Jan 17 14:06:14 2007 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-10630&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-10631  width='300' align='top'></a></td><td><h3>Store 5183. Init Lumi. 251e30</h3> 
Silicon was integrated from the start. SVTSpyMon and SVXMon plots look OK. 
</td></tr></table>
<!-- Author: Satyajit -->



<!-- Date: Wed Jan 17 23:40:22 2007 -->
<h4>Too many 
<a href= 
'/cgi/elog/elog.pl?nb=2007&action=view&page=51&frame=2&anchor=23:03:32.492'> 
bias pinkies</a>  
at a time!</h4> 
Around 10:40pm I got a page from the SciCo that about 7 bias  
pinkies have appeared on SVX L0,1 within last 5 mins. While I 
was speaking another 3 joined the band. I first made sure there 
is no unusual beam activity linked to this event. Looks like  
all these ladders crossed their original bias limit (100 uA) at 
the same time and the jumps are not large. In consultation with 
Jose, I asked the SciCo to ignore these ladders. We will bump up 
their limits tomorrow.
<!-- Author: Satyajit & Jose -->

<!-- Date: Thu Jan 18 08:35:24 2007 -->
Entered in Silicon database: <ul>
<li>Ladder: SB3W6L1 
<li>problem n: 1763 
<li>Status: fixed
<li>Type: BIAS
<li>Action: IMON_limits
<li>entered by: satyajit 
<li>description is: Bump up the upper limit some more.<table border=1>
<tr><th>IMON LIMITS</th><th>Old</th><th>New</th></tr>
<tr><td><b>Nominal</b></td><td>64.3784</td><td>110.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>120.0</td><td>140.0</td></tr></table> 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B3W6&layer=L1">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Thu Jan 18 08:45:10 2007 -->
Entered in Silicon database: <ul>
<li>Ladder: SB2W8L0 
<li>problem n: 1885 
<li>Status: fixed
<li>Type: BIAS
<li>Action: IMON_limits
<li>entered by: satyajit 
<li>description is: Bumping up upper limit.<table border=1>
<tr><th>IMON LIMITS</th><th>Old</th><th>New</th></tr>
<tr><td><b>Nominal</b></td><td>49.5708</td><td>90.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>120.0</td></tr></table> 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B2W8&layer=L0">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Thu Jan 18 08:49:19 2007 -->
Entered in Silicon database: <ul>
<li>Ladder: SB2W8L1 
<li>problem n: 1886 
<li>Status: fixed
<li>Type: BIAS
<li>Action: IMON_limits
<li>entered by: satyajit 
<li>description is: Bumping up upper limit.<table border=1>
<tr><th>IMON LIMITS</th><th>Old</th><th>New</th></tr>
<tr><td><b>Nominal</b></td><td>47.1935</td><td>90.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>120.0</td></tr></table> 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B2W8&layer=L1">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Thu Jan 18 08:59:16 2007 -->
Entered in Silicon database: <ul>
<li>Ladder: SB0W9L2 
<li>problem n: 1699 
<li>Status: needs_longterm_monitoring
<li>Type: BIAS
<li>Action: IMON_limits
<li>entered by: satyajit 
<li>description is: Bumping up upper limit.<table border=1>
<tr><th>IMON LIMITS</th><th>Old</th><th>New</th></tr>
<tr><td><b>Nominal</b></td><td>280.0</td><td>280.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>300.0</td><td>320.0</td></tr></table> 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B0W9&layer=L2">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Thu Jan 18 09:10:51 2007 -->
Entered in Silicon database: <ul>
<li>Ladder: SB3W10L1 
<li>problem n: 1887 
<li>Status: fixed
<li>Type: BIAS
<li>Action: IMON_limits
<li>entered by: satyajit 
<li>description is: Bumping up upper limit.<table border=1>
<tr><th>IMON LIMITS</th><th>Old</th><th>New</th></tr>
<tr><td><b>Nominal</b></td><td>46.6168</td><td>90.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>120.0</td></tr></table> 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B3W10&layer=L1">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Thu Jan 18 09:15:50 2007 -->
Entered in Silicon database: <ul>
<li>Ladder: SB3W6L0 
<li>problem n: 1800 
<li>Status: fixed
<li>Type: BIAS
<li>Action: IMON_limits
<li>entered by: satyajit 
<li>description is: Bumping up limits.<table border=1>
<tr><th>IMON LIMITS</th><th>Old</th><th>New</th></tr>
<tr><td><b>Nominal</b></td><td>110.0</td><td>110.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>120.0</td><td>140.0</td></tr></table> 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B3W6&layer=L0">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Thu Jan 18 09:22:40 2007 -->
Entered in Silicon database: <ul>
<li>Ladder: SB4W5L0 
<li>problem n: 1888 
<li>Status: fixed
<li>Type: BIAS
<li>Action: IMON_limits
<li>entered by: satyajit 
<li>description is: Bumping up upper limit.<table border=1>
<tr><th>IMON LIMITS</th><th>Old</th><th>New</th></tr>
<tr><td><b>Nominal</b></td><td>48.0293</td><td>90.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>120.0</td></tr></table> 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B4W5&layer=L0">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Thu Jan 18 09:26:39 2007 -->
Entered in Silicon database: <ul>
<li>Ladder: SB4W5L1 
<li>problem n: 1889 
<li>Status: fixed
<li>Type: BIAS
<li>Action: IMON_limits
<li>entered by: satyajit 
<li>description is: Bumping up limits.<table border=1>
<tr><th>IMON LIMITS</th><th>Old</th><th>New</th></tr>
<tr><td><b>Nominal</b></td><td>45.3079</td><td>90.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>120.0</td></tr></table> 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B4W5&layer=L1">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Thu Jan 18 09:30:48 2007 -->
Entered in Silicon database: <ul>
<li>Ladder: SB4W6L0 
<li>problem n: 1890 
<li>Status: fixed
<li>Type: BIAS
<li>Action: IMON_limits
<li>entered by: satyajit 
<li>description is: Bumping up limits.<table border=1>
<tr><th>IMON LIMITS</th><th>Old</th><th>New</th></tr>
<tr><td><b>Nominal</b></td><td>41.0036</td><td>90.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>120.0</td></tr></table> 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B4W6&layer=L0">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Thu Jan 18 09:34:07 2007 -->
Entered in Silicon database: <ul>
<li>Ladder: SB5W1L0 
<li>problem n: 1891 
<li>Status: fixed
<li>Type: BIAS
<li>Action: IMON_limits
<li>entered by: satyajit 
<li>description is: Bumping up limits.<table border=1>
<tr><th>IMON LIMITS</th><th>Old</th><th>New</th></tr>
<tr><td><b>Nominal</b></td><td>52.3208</td><td>100.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>120.0</td></tr></table> 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B5W1&layer=L0">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Thu Jan 18 09:36:36 2007 -->
Entered in Silicon database: <ul>
<li>Ladder: SB5W1L1 
<li>problem n: 1892 
<li>Status: fixed
<li>Type: BIAS
<li>Action: IMON_limits
<li>entered by: satyajit 
<li>description is: Bumping up limits.<table border=1>
<tr><th>IMON LIMITS</th><th>Old</th><th>New</th></tr>
<tr><td><b>Nominal</b></td><td>53.5553</td><td>100.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>120.0</td></tr></table> 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B5W1&layer=L1">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Thu Jan 18 09:44:41 2007 -->
Entered in Silicon database: <ul>
<li>Ladder: LB0W5L3 
<li>problem n: 1893 
<li>Status: fixed
<li>Type: BIAS
<li>Action: IMON_limits
<li>entered by: satyajit 
<li>description is: Bumping up limits.<table border=1>
<tr><th>IMON LIMITS</th><th>Old</th><th>New</th></tr>
<tr><td><b>Nominal</b></td><td>49.9508</td><td>90.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>120.0</td></tr></table> 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=L00&wedge=B0W5&layer=L3">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Thu Jan 18 09:47:22 2007 -->
Entered in Silicon database: <ul>
<li>Ladder: LB0W4L3 
<li>problem n: 1894 
<li>Status: fixed
<li>Type: BIAS
<li>Action: IMON_limits
<li>entered by: satyajit 
<li>description is: Bumping up limits.<table border=1>
<tr><th>IMON LIMITS</th><th>Old</th><th>New</th></tr>
<tr><td><b>Nominal</b></td><td>43.8345</td><td>90.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>120.0</td></tr></table> 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=L00&wedge=B0W4&layer=L3">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Thu Jan 18 09:57:05 2007 -->
Entered in Silicon database: <ul>
<li>Ladder: SB3W9L1 
<li>problem n: 1895 
<li>Status: fixed
<li>Type: BIAS
<li>Action: IMON_limits
<li>entered by: satyajit 
<li>description is: This one is very close to its upper limit (yellow). Bumping up in anticipation.<table border=1>
<tr><th>IMON LIMITS</th><th>Old</th><th>New</th></tr>
<tr><td><b>Nominal</b></td><td>45.7864</td><td>90.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>120.0</td></tr></table> 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B3W9&layer=L1">report</a></ul>
<!-- Author: Problem DB -->



<!-- Date: Thu Jan 18 10:04:15 2007 -->
<b>An one hour access is coming up at 11 am</b>, after the end of 
the current store. We will do some quiet time studies.  
<!-- Author: Satyajit -->
<!-- Comment: Thu Jan 18 11;04;49 comment by...Ulrich -->
The Silicon went to STANDBY a little before the end of the store because of a TEL2 end-of-store study. We only learned about these studies through a plan which was posted 30 minutes earlier: <tt>TEL2 B11 BPM study 30min.</tt> (whatever that means...). A little more planning ahead on the accelerator side would be useful.
<!-- Comment: Thu Jan 18 12;32;56 comment by...ronmoore -->
The study plan was discussed at the AD 09:00 meeting; it should not have been a surprise.
<!-- Comment: Thu Jan 18 14;19;08 comment by...Ulrich -->
Well, no Silicon expert is at the 9:00 meeting. I would have expected that this is discussed 1 day in advance, not 1 hour.
<!-- Comment: Fri Jan 19 15;32;52 comment by...Ulrich -->
<p>
Speaking of short notice:
<pre>
15:23:45-   There will be a parasitic EOS study that will tickle the beam. This should not affect the experiments. This will begin at about 15:30. CDF and D0 have been notified. - S.Chaurize  
</pre>
<!-- Date: Thu Jan 18 10:57:26 2007 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-10636&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-10637  width='300' align='top'></a></td><td>When the detector was already in standby, the DVDD current for e414 increased (same thing happened last week). Some coldstarts were needed to put down the current.</td></tr></table>
<!-- Author: Sebastian and Jose -->


<!-- Date: Thu Jan 18 12:24:09 2007 -->
Entered in Silicon database: <ul>
<li>Ladder: SB0W11L4 
<li>problem n: 1877 
<li>Status: needs_observation
<li>Type: AVDD2
<li>Action: Diagnosis_update
<li>entered by: mhartz 
<li>description is: We took a look at this ladder in svxdaq.  With the most realistic data taking settings we saw data from the full phi side for about 90% of events, but the z side is missing for all events.  We updated the chip settings to readout the phi side and chopped the chain after chip 87.  We need to keep an eye on the currents to see if this recovers at some point. 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B0W11&layer=L4">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Thu Jan 18 12:24:09 2007 -->
Entered in Silicon database: <ul>
<li>Ladder: SB0W11L4 
<li>problem n: 1877 
<li>Status: needs_observation
<li>Type: AVDD2
<li>Action: Diagnosis_update
<li>entered by: mhartz 
<li>description is: We took a look at this ladder in svxdaq.  With the most realistic data taking settings we saw data from the full phi side for about 90% of events, but the z side is missing for all events.  We updated the chip settings to readout the phi side and chopped the chain after chip 87.  We need to keep an eye on the currents to see if this recovers at some point. 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B0W11&layer=L4">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Thu Jan 18 12:25:48 2007 -->
Entered in Silicon database: <ul>
<li>Ladder: SB0W5L2 
<li>problem n: 1829 
<li>Status: needs_work
<li>Type: DRO_00F3
<li>Action: Diagnosis_update
<li>entered by: sasha 
<li>description is: This ladder looses 1st chip in ~20% of cases, and, as a consiquence, the read out is dropped. We find that by changing DPS off and raising threshold to PED+9 fixes the problem at the cost of large increase (x10 fold) of DVDD current drawn by that chip. We are not sure if it's a safe condition for a chip. So, we're not going to make any changes unless error rate goes to ~80% or we loose another ladder in this wedge. 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B0W5&layer=L2">report</a></ul>
<!-- Author: Problem DB -->





<!-- Date: Thu Jan 18 15:39:56 2007 -->
<br><b>Turbo HRR test</b><br><br> 
 
Run Control was not ready for the turboHRR test yet. In 
fact the tstsvx1 RC configration is not longer working (since  
b0svx09 was added). Bill recompiled the fer code to be able to use tstsvx1 with RC again. Now it's working, tstsvx1 now subscribes to 
/src/vrb/10 (tstsvx2 to 11)<br> 
However, when running with RC I don't see any signals arriving to the SRC! And was surprised to see them there when the L2 people were running RC in partition 0. I asked Bill and Jonathan about this and they are not suer what is going on at this point. SCN would figure this out easily..
<!-- Author: Sebastian -->
<!-- Comment: Fri Jan 19 09;30;21 comment by...Sebastian -->
From Steve Nahn:<pre>
By the way to Sebastian-I don't instantly know why the TEST SRC reincarnation
didn't work, but you said you didn't get any signals from the TS.  That would
mean either the TXPT/RXPT maps were screwed up, or maybe the clock signals?  To
play with the TS you need the real clock, of course, and if you've swapped SRCs
around you should make ssure all the jumpers are correct for clock phase.  Also
I would try to turn offline all the other cards in the crate, or at least the
FIB ones.  Vrb will be okay I guess-probably gets its J3 connection disabled if
it doesn't map to a FIB.  I believe the software only handles a VRB crate XOR a
FIB crate, not both.  That's an upgrade we never did (although it wouldn't be
too hard, probably just have to make a new level of nested ReadoutList...)</pre>
<!-- Comment: Fri Jan 19 09;32;37 comment by...Sebastian -->
My reply to Steve:
thanks for your input. I know the clock was ok, I saw the 
signals and the SRC with the TSemulation was working fine. 
As I said in the log book the strange thing was that I did 
saw signals comig from the TS but these were not generated 
by my RC session (which I was running in partition 1), but 
from Vadim's session, which was running in partition 0. They 
were swapping L2 machines and cables so I guess this could 
have been part of the problem and the reason their test did 
not work.<br><br>
I will try this again when nobody is making changes to L2.
<!-- Date: Thu Jan 18 17:33:50 2007 -->
<h3>SVXINTER connected to TevMon permit</h3> 
Today Jonathan Lewis has moved over the patch panel to connect a BNC cable to the SVXINTER crate CPU's mezzanine card. The panel was installed at the test stand is now in place. At this point all cables are connected: from the C184 card in the 2nd floor TeV rack to a patch panel in the rack, via a BNC cable to the patch panel at SVXINTER, and from there into the mezzanine card. So at this point Bill Badgett should be able to pick up the signal and Dean can test his code in situ. 
<p> 
During this work, somehow the power cord for the SVXIICON monitor and the switch for the internal network to read the PLC slipped out of the outlet. I realized that when I saw the Silicon iFix readings missing. Luckily this was no big deal, everything came back fine after I reseated the cord. 
<!-- Author: Ulrich -->
<!-- Comment: Thu Jan 18 19;59;30 comment by...Bill, Jose, Ulrich -->
<p>
While CDF is not able to take data, Bill Badgett and I did another test for TevMon. Bill loaded his code to pick up the permit signal into SVXINTER:
<pre>
svxinter-> cd "b0vxboot02:/cdf/onln/home/badgett/caencontrol/server/lib/VxWorks-5.3/ppc"
value = 0 = 0x0
svxinter-> ld < BeamPermit.o
value = 13074768 = 0xc78150
svxinter-> BeamPermit_init()
PMC464 BoardAddress    0xC1500000
PMC464 InterruptVector       0x19
value = 0 = 0x0
svxinter-> BeamPermit_print()
InterruptCounter          0   Up: 0  Down: 0
InterruptRegister         0x00000001
InputSignals    <31:00>   0xFFFFFFFE
InputSignals    <63:32>   0xFFFFFFFE
InterruptStatus <31:00>   0x00000000
InterruptStatus <63:32>   0x00000000
InterruptEnable <31:00>   0x00000001
InterruptEnable <63:32>   0x00000001
InterruptType   <31:00>   0x00000001
InterruptType   <63:32>   0x00000001
</pre>
This prgramm just reads out all 64 bits of the mezzanine card's register. The least significant bit is not set, as you would expect for a inhibit signal. This is how we would like to have the system working, because when the cable is disconnected, the signal will float high, and Silicon should go to STANDBY. We tested this by disconnecting the cable and got the following:
<pre>
svxinter-> BeamPermit_print()
InterruptCounter          1   Up: 1  Down: 0
InterruptRegister         0x00000002
InputSignals    <31:00>   0xFFFFFFFF
InputSignals    <63:32>   0xFFFFFFFF
InterruptStatus <31:00>   0x00000001
InterruptStatus <63:32>   0x00000001
InterruptEnable <31:00>   0x00000001
InterruptEnable <63:32>   0x00000001
InterruptType   <31:00>   0x00000001
InterruptType   <63:32>   0x00000001
value = 37 = 0x25 = '%'
</pre>
So the interrupt counter was incremented, and the LSB was indeed 1 without the cable. When we re-connected the cable, the bit went low again, but the interrupt counter was not incremented. According to Bill, Dean's part of the code has to release the interrupt. This way, a second interrupt is suppressed while Dean's code is still busy.
<p>
This test shows two important things:
<ol>
<li>Ron's permit signal has the correct polarity, it is low whenever the Silicon is safe, and high otherwise. Unfortunately, the DSTAT page of E:SVXPMT is red and shows "Inhibit" when this happens.</li>
<li>The chain from Ron's OAC through the C184 module all the way to SVXINTER works.</li>
</ol>
The next step will be to test Dean's code on SVXINTER to see if a dropped permit really puts the Silicon to STANDBY.
<!-- Comment: Thu Jan 18 21;58;59 comment by...Satyajit -->
Today at the beginning of the record lumi. store we got a pop-up
saying LOSTP RMS too high and asked to bring silicon to standby.
We didn't take any action because there was no apparent (strange)
beam activity at that time. We need to be extra cautious now that
we are planning to use TevMon's output to bring silicon to standby
automatically.

<!-- Comment: Thu Jan 18 22;08;30 comment by...Ulrich -->
I pointed this out to Ron Moore (C:LOSTP is still in Warning), and he found a bug in TevMon which he promised to fix tomorrow. That's why we want to validate the new TevMon carefully before we put it online.
<!-- Comment: Fri Jan 19 11;40;57 comment by...ronmoore -->
The C:LOSTP RMS problem is a WARNING only, not ALARM...why would the monitor say Si should go to standby for a warning?
<!-- Comment: Fri Jan 19 17;20;15 comment by...Ulrich -->
<p>
Today Ron came to the control room twice to do a couple of final tests with the new TevMon. In the early afternoon he fixed a problem with the alarm/warning limits on the  RMS of C:LOSTP. After the last store had been dropped, he inverted the output signal of the C184 module (which turned out to have the wrong polarity, despite of my claims yesterday). Now the signal acts as an inhibit. It is HI if TevMon is in alarm or a cable is disconnected, and it is low otherwise.
<!-- Comment: Sun Jan 21 12;27;18 comment by...Satyajit -->
<pre>If the C:LOSTP RMS issues a WARNING and not an ALARM, we 
should fix our code not to ask the shift crew to bring silicon
to standby.
</pre>
<!-- Date: Thu Jan 18 18:23:52 2007 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-10638&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-10639  width='300' align='top'></a></td><td><h3>Store 5186, Inst. Lumi. 270e30 
(<font color=red>A new record!</font>)</h3> 
Silicon was integrated from the start. SVTSpyMon and SVXMon 
plots look fine.</td></tr></table>
<!-- Author: Satyajit, Jose -->

<!-- Date: Thu Jan 18 18:27:58 2007 -->
Entered in Silicon database: <ul>
<li>Ladder: SB3W8L2 
<li>problem n: 1773 
<li>Status: fixed
<li>Type: BIAS
<li>Action: IMON_limits
<li>entered by: satyajit 
<li>description is: Bumping up limit.<table border=1>
<tr><th>IMON LIMITS</th><th>Old</th><th>New</th></tr>
<tr><td><b>Nominal</b></td><td>100.0</td><td>110.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>120.0</td><td>140.0</td></tr></table> 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B3W8&layer=L2">report</a></ul>
<!-- Author: Problem DB -->



<!-- Date: Thu Jan 18 18:51:57 2007 -->
At the beginning of the store there was  
<a href= 
'/cgi/elog/elog.pl?nb=2007&action=view&page=54&frame=2&anchor=18:20:23.083'> 
an AVDD pinkie</a> 
on SVX B0W11L4. It clears out on an HRR or CONFIG but soon climbs 
back up (by about 200 mA). It has a history of AVDD incidents. Will 
keep watching.
<!-- Author: Satyajit -->
<!-- Comment: Thu Jan 18 19;37;46 comment by...Ulrich -->
Let's keep in mind that Sasha and Mark worked on this ladder earlier today. The have included the rest of the &phi; side, so that we have 7/14 chips running (instead of 2/14 before). If this ladder really shows AVDD2-like behavior, i.e. the DVDD current leaks into the AVDD line, then we would expect larger AVDD currents correlated with DVDD. This is exactly what we see. So I think we just have to adjust the IMON limits for AVDD to a limit which is ok during data-taking. Ricardo and I recently adjusted the trip limit to 1600 mA, which is still a bit away from the largest AVDD current we observed (1430 mA).


<!-- Comment: Thu Jan 18 20;02;09 comment by...Ulrich -->
We have put AVDD for e0b4 to IGNORE for the time being. Let's watch it for a day and adjust the limits if required.



<!-- Comment: Fri Jan 19 08;48;27 comment by...Satyajit -->
Bumped up the upper limit to 1430 mA.
<!-- Comment: Fri Jan 19 11;09;33 comment by...Mark -->
Sorry we forgot to adjust the IMON limits yesterday. 
<!-- Date: Fri Jan 19 08:28:56 2007 -->
Entered in Silicon database: <ul>
<li>Ladder: SB0W11L4 
<li>problem n: 1877 
<li>Status: needs_observation
<li>Type: AVDD2
<li>Action: IMON_limits
<li>entered by: satyajit 
<li>description is: The oscillatory AVDD2-like behaviour is back. As expected, this is correlated with a similar pattern in DVDD. Bumping up the upper limit, remaining within the hardware limit of 1600 mA.<table border=1>
<tr><th>IMON LIMITS</th><th>Old</th><th>New</th></tr>
<tr><td><b>Nominal</b></td><td>991.009</td><td>1300.0</td></tr>
<tr><td><b>Lower</b></td><td>980.0</td><td>980.0</td></tr>
<tr><td><b>Upper</b></td><td>1290.0</td><td>1430.0</td></tr></table> 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B0W11&layer=L4">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Fri Jan 19 08:44:59 2007 -->
Entered in Silicon database: <ul>
<li>Ladder: IB0W2L3 
<li>problem n: 1774 
<li>Status: needs_observation
<li>Type: BIAS
<li>Action: IMON_limits
<li>entered by: satyajit 
<li>description is: Ramp of the Bias0 rise seems to be increasing. bumping up the limits.<table border=1>
<tr><th>IMON LIMITS</th><th>Old</th><th>New</th></tr>
<tr><td><b>Nominal</b></td><td>80.0</td><td>105.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>110.0</td><td>140.0</td></tr></table> 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=ISL&wedge=B0W2&layer=L3">report</a></ul>
<!-- Author: Problem DB -->




<!-- Date: Fri Jan 19 08:56:34 2007 -->
<center><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-10640&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-10641' ></a><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-10642&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-10643' ></a></center>
<!-- Author: Satyajit -->
<!-- Comment: Fri Jan 19 09;04;39 comment by...Satyajit -->
AVDD and DVDD history for SB0W11L4.





<!-- Date: Fri Jan 19 15:29:13 2007 -->
Entered in Incident database: <ul>
<li>Submitted by: husemann
<li>Description of Problem: We had a weird network glitch that froze all PCs in the control room for a while. This also affected b0dasvxXX. Everything came back fine after a while, but we got an alarm on SVX, ISL, and L00 for a short time which cleared itself. I have also checked the iFix PC downstairs. I was too late to find any trace of the problem, but I realized that TempOut.exe had problems re-subscribing to the RTserver. I restarted the program, and it came back fine.
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/idb/DBentry.pl?incident_number=107">Incident Report</a></ul>
<!-- Author: Incident DB -->



<!-- Date: Fri Jan 19 15:34:58 2007 -->
Entered in Silicon database: <ul>
<li>Ladder: SB0W11L4 
<li>problem n: 1896 
<li>Status: fixed
<li>Type: BIAS
<li>Action: IMON_limits
<li>entered by: husemann 
<li>description is: Bumping up bias limit.<table border=1>
<tr><th>IMON LIMITS</th><th>Old</th><th>New</th></tr>
<tr><td><b>Nominal</b></td><td>47.2444</td><td>100.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>125.0</td></tr></table> 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B0W11&layer=L4">report</a></ul>
<!-- Author: Problem DB -->



<!-- Date: Fri Jan 19 15:37:44 2007 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-10645&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-10645  width='300' align='top'></a></td><td> </td></tr></table>
<!-- Author: Jose -->

<!-- Date: Fri Jan 19 15:39:34 2007 -->
Entered in Silicon database: <ul>
<li>Ladder: SB0W3L1 
<li>problem n: 1897 
<li>Status: fixed
<li>Type: BIAS
<li>Action: IMON_limits
<li>entered by: husemann 
<li>description is: Bumping up bias current limit.<table border=1>
<tr><th>IMON LIMITS</th><th>Old</th><th>New</th></tr>
<tr><td><b>Nominal</b></td><td>52.6785</td><td>100.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>125.0</td></tr></table> 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B0W3&layer=L1">report</a></ul>
<!-- Author: Problem DB -->



<!-- Date: Fri Jan 19 15:46:55 2007 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-10648&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-10648  width='300' align='top'></a></td><td>This plot and the previous (SB4W8) show the behavior of two power supplies swapped on December (~ day 2170). Both showed a dropping DVDD and were fixed at Prep. After one month of running they seem to be fine.</td></tr></table>
<!-- Author: Jose -->

<!-- Date: Fri Jan 19 15:48:45 2007 -->
Entered in Silicon database: <ul>
<li>Ladder: IB3W1L0 
<li>problem n: 1605 
<li>Status: fixed
<li>Type: BIAS
<li>Action: IMON_limits
<li>entered by: husemann 
<li>description is: Bumping up Bias1 current limit again.<table border=1>
<tr><th>IMON LIMITS</th><th>Old</th><th>New</th></tr>
<tr><td><b>Nominal</b></td><td>100.0</td><td>150.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>150.0</td><td>180.0</td></tr></table> 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=ISL&wedge=B3W1&layer=L0">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Fri Jan 19 16:08:39 2007 -->
Entered in Silicon database: <ul>
<li>Ladder: SB0W11L4 
<li>problem n: 1877 
<li>Status: needs_work
<li>Type: jumper
<li>Action: Diagnosis_update
<li>entered by: mhartz 
<li>description is: This ladder is seeing no first chip ~70% of the time.  Also, the loss of the z-side looks like a jumper failure, not an AVDD2 failure as the previous entries indicate.  There was no corresponding firing of the ghostbuster, so it is not clear if this could have been related to a synchronous readout condition. 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B0W11&layer=L4">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Fri Jan 19 16:08:39 2007 -->
Entered in Silicon database: <ul>
<li>Ladder: SB0W11L4 
<li>problem n: 1877 
<li>Status: needs_work
<li>Type: jumper
<li>Action: Diagnosis_update
<li>entered by: mhartz 
<li>description is: This ladder is seeing no first chip ~70% of the time.  Also, the loss of the z-side looks like a jumper failure, not an AVDD2 failure as the previous entries indicate.  There was no corresponding firing of the ghostbuster, so it is not clear if this could have been related to a synchronous readout condition. 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B0W11&layer=L4">report</a></ul>
<!-- Author: Problem DB -->




<!-- Date: Fri Jan 19 17:44:24 2007 -->
The settings for the DMode calibration are back to they previous configuration. The next calibration will be taken with the "standard" configuration.
<!-- Author: Jose -->

<!-- Date: Fri Jan 19 17:52:57 2007 -->
Entered in Silicon database: <ul>
<li>Ladder: SB0W11L4 
<li>problem n: 1877 
<li>Status: needs_work
<li>Type: jumper
<li>Action: Diagnosis_update
<li>entered by: sasha 
<li>description is: We looked at other ladders with jumper failures. It's interesting that some of them have similar problems of DRO. Apparently, setting Rdriver on r-phi chips to 7 helped to recover DRO problems on those ladders. So, we decided to set Rdriver to 7 for this one too. Let's see what happens next. 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B0W11&layer=L4">report</a></ul>
<!-- Author: Problem DB -->



<!-- Date: Fri Jan 19 18:26:45 2007 -->
<h3>Brief Study of Jumper Failures</h3> 
Given the phi side readout problems that e0b4 has been seeing since what looks like a jumper failure last Friday, we made a review of previous jumper failures looking for dropped readout.  This is what we saw: 
<br> 
<TABLE border="1"> 
<TR><TH>Ladder<TH>Phi side DRO?<TH>Phi side Rdriver 
<TR><TH>e044<TD>None<TD>1 
<TR><TH>e074<TD>No first chip<TD>7 
<TR><TH>e033<TD>Maybe?<TD>7 
<TR><TH>e380<TD>None<TD>4 
<TR><TH>e4a4<TD>Maybe?<TD>7 
<TR><TH>e494<TD>25% DRO<TD>7 
<TR><TH>e531<TD>None<TD>7 
<TR><TH>e022<TD>DRO, but much later<TD>5, 7 for first chip 
<TR><TH>e122<TD>DRO<TD>7 
<TR><TH>e290<TD>None<TD>1 
<TR><TH>e550<TD>None<TD>4 
<TR><TH>e579<TD>None<TD>4 
<TR><TH>e579<TD>DRO<TD>7 
</TABLE> 
<br> 
So we concluded that phi side dropped readout can be associated with a jumper failure, and the way to fix it is to bump the rdrivers up to 7.  We have done this for e0b4.
<!-- Author: Sasha & Mark -->


<!-- Date: Fri Jan 19 18:35:29 2007 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-10649&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-10650  width='300' align='top'></a></td><td>Store 5187 in with intial luminosity of 225e30.  SVXMon looks ok.  SVTSPYMon looks fine.</td></tr></table>
<!-- Author: Mark -->


<!-- Date: Fri Jan 19 18:43:12 2007 -->
<center><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-10651&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-10652' ></a><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-10653&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-10653' width='300'></a></center>
<!-- Author: Mark -->
<!-- Comment: Fri Jan 19 18;48;11 comment by...Mark -->
Occupancies for e0b4 phi side before (left) and after (right) the rdriver changes to 7.  A check of the error logger confirms that this ladder is no longer dropping readout on the phi side.  Unfortunately this seems to definitely confirm that we have experienced a jumper failure.  Since there was no resonance detected in this case, we may want to revisit the 13 tick setting for the ghostbuster.  Any suggestions from the peanut gallery?



<!-- Date: Sat Jan 20 11:41:33 2007 -->
<h3>SVX All Yellow in SVXMon</h3> 
Last night the shift crew <a href= 
'http://www-cdfonline.fnal.gov/cgi/elog/elog.pl?nb=2007&action=view&page=58&frame=2&anchor=00:53:47.280'> 
documented</a> another run (232494) in which all of SVX did not return any data in SVXMon. They started a new run, and the problem went away. I have looked at a couple of more SVXMon plots in Bill Badgett's <a href="http://www-cdfonline.fnal.gov/java/cdfdb/servlet/ConsumerBrowser?RUN=232494">ConsumerRootFileBrowser</a>. First of all, they made the right call. SVXMon had 170 events from that run, and yet it was all yellow in SVX. Also our favorite ISL FIB was yellow (f320). Of course we had no chance to read out any registers on the VRBs in the middle of the night to see what cause the problem, but we should have a look at the raw data.  
<!-- Author: Ulrich -->
<!-- Comment: Sat Jan 20 16;33;41 comment by...Mark -->
Looks like the same problem as last time which strange data in between the pointer table and the data.  I will fire off an email to Conor.
<pre>
      360: 00004e0c 00004e34 00020000 01010000
      364: 03030202 05050404 07070606 09090808
      368: 0b0b0a0a 0d0d0c0c 0f0f0e0e 11111010
      372: 13131212 15151414 17171616 19191818
      376: 1b1b1a1a 1d1d1c1c 1f1f1e1e 21212020
      380: 23232222 25252424 27272626 29292828
      384: 2b2b2a2a 2d2d2c2c 2f2f2e2e 31313030
      388: 33333232 35353434 37373636 39393838
      392: 3b3b3a3a 3d3d3c3c 3f3f3e3e 41414040
      396: 43434242 45454444 47474646 49494848

      400: 4b4b4a4a 4d4d4c4c 4f4f4e4e 51515050
      404: 53535252 55555454 57575656 59595858
      408: 5b5b5a5a 5d5d5c5c 5f5f5e5e 61616060
      412: 63636262 65656464 67676666 69696868
      416: 6b6b6a6a 6d6d6c6c 6f6f6e6e 71717070
      420: 73737272 75757474 77777676 79797878
      424: 7b7b7a7a 7d7d7c7c 7f7f7e7e 01010000
      428: ...
</pre>
<!-- Comment: Sat Jan 20 17;00;38 comment by...Mark -->
As for f32x, I took a look at the data, and the HDIs are completely missing (shouldn't this give us reformatter errors?).:
<pre>
     4736: 0000c1c1 03fc<b>f314</b> 00f38f25 360a3501
     4740: 190137f3 1b061a09 2d0d2cf3 8e252ef3
     4744: 310a3009 8d2532f3 0f090ef3 8c2510f3
     4748: 39093801 9b253a04 2b092af3 30062c04
     4752: 32093109 35f33304 37093609 3b073803
     4756: 3d083c09 220b2106 24092301 35f325f3
     4760: 3703360b 9a253ff3 0108000b 0d0a0c06
     4764: 15070e06 17031609 280927f3 32052905
     4768: 34f3330b 17f39925 19f31809 16f39825
     4772: 18021709 2f01b725 3107300a 3d0a3c02
     4776: 30073ef3 32013109 b525b625 1b091af3
     4780: 2a061cf3 2c072b0b a325b425 a125a225
     4784: 1a0e19f3 a0251b01 c2c23f01 03fc<b>f400</b>
     4788: 00018f25 14f38e25 16031509 8c258d25
</pre>
<a href=
'/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=331&frame=2&anchor=11:41:52'>
Previously</a> when f32x was showing up as no data in SVXMon, it looked like the VRB was getting into WYSYWIG mode.  We did a VRB swap, and now the symptoms look different.  Maybe we should try this VRB in a different slot.

<!-- Comment: Sat Jan 20 17;13;54 comment by...Mark -->
If f32x misbehaves again when a Siliconer is around, it might be useful to go to halt and get screen shots of the VRB and FIB status pages in svxdaq.
<!-- Date: Sat Jan 20 11:42:16 2007 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-10654&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-10654  width='300' align='top'></a></td><td>The above incident also showed a mapping error in the new SVXMon slides: it should show all of f32x yellow, but shows also one ladder (i.e half of the DAQ ladder) in f310 yellow.</td></tr></table>
<!-- Author: Ulrich -->
<!-- Comment: Sat Jan 20 12;25;15 comment by...Jose -->
It is a pity that it happened when we were not there. We could not debug the problem. By the way, I have to do some fixes in the slides...
<!-- Date: Sat Jan 20 11:45:46 2007 -->
Entered in Incident database: <ul>
<li>Submitted by: husemann
<li>Description of Problem: Spontaneous switch-off of CAEN crate #13. Recovered fine by Aces. Trying to teach them that they don't need "Reset Trips" for these incidents.
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/idb/DBentry.pl?incident_number=108">Incident Report</a></ul>
<!-- Author: Incident DB -->




<!-- Date: Sat Jan 20 13:34:32 2007 -->
<center><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-10655&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-10656' ></a><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-10657&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-10658' ></a><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-10659&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-10660' ></a></center>
<!-- Author: sasha -->
<!-- Comment: Sat Jan 20 13;57;39 comment by...sasha -->
This is a current history during past ~2 hours for e380. As one can see all three currents have similar behaviour. It's interesting that this ladder also developped "No HDI" problem earlier today. I gues what could have happened is that one of the r-phi chips was lost and came back later. A jump of ~80 in Avdd seems to indicate this. Also notice that this ladder is a "jumper failure" victim. So, it looks like e380 also developped problems with r-phi chips similar those reported in this <a href=
'http://www-cdfonline.fnal.gov/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=336&frame=2&anchor=18:26:45'>entry</a>. So, I would suggest to change Rdriver to 7 for r-phi chips in between stores or whenever we have a chance to do that.


     




<!-- Date: Sat Jan 20 19:19:03 2007 -->
<p><font size=+1> D-mode Calibration Job Started </font>
<p><pre>
Job id            : 458
Calibration type  : standard
Run period tag    : Jan_2007
DPS-off run       : 232509
DPS-on run        : 232508
Requested by      : Jan Lueck
Main process id   : 20165
</pre>
<!-- Author: CDF silicon D-mode calibration job server v1.4 -->



<!-- Date: Sat Jan 20 23:42:59 2007 -->
Around 7:20 pm I was paged by the SciCo that there are  
<a href= 
'/cgi/elog/elog.pl?nb=2007&action=view&page=60&frame=2&anchor=19:51:41.442'> 
too many pinkies</a>  
during the D-Mode calibration. I assured her that this is 
expected and HRRs should fix them. She also pointed out that 3 
instances of IMON are running. I told her to wait till the end  
of the store and stop all but one. Just now I instructed the ACE 
<a href= 
'/cgi/elog/elog.pl?nb=2007&action=view&page=60&frame=2&anchor=23:08:41.189'> 
to do that</a> while the final protons are being loaded. Also  
currently there is a  
<a href= 
'/cgi/elog/elog.pl?nb=2007&action=view&page=60&frame=2&anchor=23:11:36.582'> 
problem running SVXMon</a>. 
I have reminded the ACE not to integrate silicon without SVXMon.  
<!-- Author: Satyajit -->
<!-- Comment: Sun Jan 21 00;05;44 comment by...Ulrich -->
A few comments:
<ul>
<li>The pinkies in two ladders during DMode calibration are expected. Why and when would you propose an HRR? They will come back fine after the calibration is over and a new run is config'ed.</li>
<li>Which version of IMON is running now? Maybe Ricardo and I didn't spread the word properly, but the current version is in <tt>~svxii/imon_dev_Jan08_2007</tt>. Jose will rename it to <tt>imon_dev</tt> and instruct the shift crew to restart IMON yet again.</li>
<li>The shift crew comments about SVXMon are confusing. It seems to me that just the display is missing, and it cannot be connected to the actual consumer because the consumer has not yet seen its first event.</li>
</ul>

<!-- Comment: Sun Jan 21 00;18;54 comment by...Ulrich -->
SVXMon is now running fine.

<!-- Comment: Sun Jan 21 00;30;25 comment by...Jose -->
imon_dev is a link pointing to ~svxii/imon_dev_Jan08_2007. The previous version is renamed as imon_2006. I have restarted IMON using the last version.


<!-- Comment: Sun Jan 21 00;37;58 comment by...Satyajit -->
By HRRs I meant CONFIG transitions between starting / stopping
D-Mode calib. runs. Yes, the consumer pager carrier identified 
the confusion with SVXMon. I wonder why multiple IMONs were
running in the first place.


<!-- Comment: Sun Jan 21 01;03;14 comment by...Jose -->
If I remmember correctly the ladders that go pink with the DMode calibration are SB0W5L2 and SB3W9L2.
<!-- Date: Sun Jan 21 00:31:00 2007 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-10661&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-10662  width='300' align='top'></a></td><td><h3>Store 5188, Initial Luminosity 63.3e30</h3> 
Silicon was integrated from the start. SVXMon and SVTSpyMon 
plots look OK.</td></tr></table>
<!-- Author: Satyajit -->
<!-- Comment: Sun Jan 21 00;39;48 comment by...Ulrich -->
The sub-optimal luminosity is apparently due to poor pbar transfer efficiencies from the recycler. They were only shooting from 230e10, and had only 60% transfer efficiency.


<!-- Date: Sun Jan 21 01:05:48 2007 -->
Entered in Silicon database: <ul>
<li>Ladder: IB3W1L1 
<li>problem n: 1898 
<li>Status: fixed
<li>Type: BIAS
<li>Action: IMON_limits
<li>entered by: jgarcian 
<li>description is: Increasing the limits for Bias0.<table border=1>
<tr><th>IMON LIMITS</th><th>Old</th><th>New</th></tr>
<tr><td><b>Nominal</b></td><td>59.8682</td><td>95.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>125.0</td></tr></table> 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=ISL&wedge=B3W1&layer=L1">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Sun Jan 21 01:09:57 2007 -->
Entered in Silicon database: <ul>
<li>Ladder: IB1W0L1 
<li>problem n: 1559 
<li>Status: fixed
<li>Type: BIAS
<li>Action: IMON_limits
<li>entered by: jgarcian 
<li>description is: Increasing limit for Bias1.<table border=1>
<tr><th>IMON LIMITS</th><th>Old</th><th>New</th></tr>
<tr><td><b>Nominal</b></td><td>81.2587</td><td>145.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>150.0</td><td>175.0</td></tr></table> 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=ISL&wedge=B1W0&layer=L1">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Sun Jan 21 01:12:01 2007 -->
Entered in Silicon database: <ul>
<li>Ladder: IB4W2L2 
<li>problem n: 1840 
<li>Status: fixed
<li>Type: BIAS
<li>Action: IMON_limits
<li>entered by: jgarcian 
<li>description is: Increasing the limits for Bias1.<table border=1>
<tr><th>IMON LIMITS</th><th>Old</th><th>New</th></tr>
<tr><td><b>Nominal</b></td><td>55.5371</td><td>95.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>125.0</td></tr></table> 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=ISL&wedge=B4W2&layer=L2">report</a></ul>
<!-- Author: Problem DB -->



<!-- Date: Sun Jan 21 01:26:32 2007 -->
<center><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-10663&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-10663' width='300'></a><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-10664&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-10664' width='300'></a></center>
<!-- Author: Jose -->
<!-- Comment: Sun Jan 21 01;28;34 comment by...Jose -->
This ladder is really getting worse. I will increase the limits a little bit.

<!-- Comment: Sun Jan 21 08;14;53 comment by...Ulrich -->
Note that we will also hit the soft trip limit again. Ricardo and I bumped it up to 700 mA last week, and it seems that we are getting close.
<!-- Date: Sun Jan 21 01:32:44 2007 -->
Entered in Silicon database: <ul>
<li>Ladder: IB0W2L0 
<li>problem n: 1786 
<li>Status: needs_observation
<li>Type: DVDD
<li>Action: IMON_limits
<li>entered by: jgarcian 
<li>description is: Increasing more the limits due to the problem with the drop on DVDD. We should try to swap this PS.<table border=1>
<tr><th>IMON LIMITS</th><th>Old</th><th>New</th></tr>
<tr><td><b>Nominal</b></td><td>400.0</td><td>400.0</td></tr>
<tr><td><b>Lower</b></td><td>300.0</td><td>300.0</td></tr>
<tr><td><b>Upper</b></td><td>600.0</td><td>650.0</td></tr></table> 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=ISL&wedge=B0W2&layer=L0">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Sun Jan 21 01:38:56 2007 -->
<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 458 finished successfully.

Job info
--------
Calibration type : standard
DPS-off run      : 232509
DPS-on run       : 232508
Requested by     : Jan Lueck
Submitted        : 2007-01-20 19:18:37
Completed        : 2007-01-21 01:38:31
Status           : SUCCESS
</pre>
<!-- Author: D-mode script run_calib_analysis.tcl -->
<!-- Comment: Sun Jan 21 02;06;31 comment by...Jose -->
This output looks much better than the previous ones...



<!-- Date: Sun Jan 21 08:16:53 2007 -->
We had a resonanace around 5:20. Logic analyzer re-armed.
<!-- Author: Ulrich -->


<!-- Date: Sun Jan 21 09:02:59 2007 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-10665&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-10665  width='300' align='top'></a></td><td>Got paged around 8:10 am that e554 has an AVDD pinkie which didn't 
respond to two HRRs. The current dropped from about 1085 to 1040 
mA, dropping below the lower limit of 1050 mA. I instructed them 
to IGNORE it for now till we investigate further. From the current 
history I see that this happened twice before in about 12 days 
intervals. We should relax the lower bound to 1030. 
</td></tr></table>
<!-- Author: Satyajit -->
<!-- Comment: Sun Jan 21 09;12;49 comment by...Ulrich -->
I think you are right. This ladder has a history of variations in the AVDD current, and the current example does not show the typical 80 mA jump you expect if a chip drops out.

<!-- Comment: Sun Jan 21 09;15;52 comment by...Satyajit -->
In the present case it recovered by itself in about an hour. It 
may still be good to adjust the lower limit.

<!-- Date: Sun Jan 21 11:32:46 2007 -->
Entered in Silicon database: <ul>
<li>Ladder: SB5W5L4 
<li>problem n: 1623 
<li>Status: fixed
<li>Type: AVDD
<li>Action: IMON_limits
<li>entered by: satyajit 
<li>description is: Reducing the AVDD current lower limit to accomodate a small transition (~40 mA) which happens infrequently. I am surprised to see that the present limits (Nominal: 1100, Lower: 1050, Upper: 1120) are not documented. <table border=1>
<tr><th>IMON LIMITS</th><th>Old</th><th>New</th></tr>
<tr><td><b>Nominal</b></td><td>1100.0</td><td>1100.0</td></tr>
<tr><td><b>Lower</b></td><td>1050.0</td><td>1030.0</td></tr>
<tr><td><b>Upper</b></td><td>1120.0</td><td>1120.0</td></tr></table> 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B5W5&layer=L4">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Sun Jan 21 12:07:24 2007 -->
Entered in Silicon database: <ul>
<li>Ladder: SB5W5L4 
<li>problem n: 1623 
<li>Status: fixed
<li>Type: AVDD
<li>Action: Diagnosis_update
<li>entered by: satyajit 
<li>description is: This is just to correct that the old nominal current in the above entry was 1060 and not 1050 mA. 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B5W5&layer=L4">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Sun Jan 21 12:07:24 2007 -->
Entered in Silicon database: <ul>
<li>Ladder: SB5W5L4 
<li>problem n: 1623 
<li>Status: fixed
<li>Type: AVDD
<li>Action: Diagnosis_update
<li>entered by: satyajit 
<li>description is: This is just to correct that the old nominal current in the above entry was 1060 and not 1050 mA. 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B5W5&layer=L4">report</a></ul>
<!-- Author: Problem DB -->




<!-- Date: Mon Jan 22 04:19:44 2007 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-10666&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-10667  width='300' align='top'></a></td><td><h3>Store 5190, Init. Lumi. 109.95E30</h3> 
SVTSpyMon and SVXMon plots look OK.</td></tr></table>
<!-- Author: Satyajit -->


<!-- Date: Mon Jan 22 05:42:47 2007 -->
Paged around 4:48 am about yellow cells in SVXMon. The CO found 
a block of yellow cells in ISL0 B3 W19-26. In the RootBrowser I 
see that strip plots for this bulkhead is empty. I was about to 
suggest the ACE to start a new Run but the MCR has suggested to 
end this store due to a beam shift caused by a separator trip.  
<!-- Author: Satyajit -->
<!-- Comment: Mon Jan 22 05;49;40 comment by...Satyajit -->
I have suggested the SciCo to mark this Run bad for silicon for
now, until we investigate things more.

<!-- Comment: Mon Jan 22 05;57;01 comment by...Satyajit -->
Here is a link to the e-log entry of the
<a href=
'/cgi/elog/elog.pl?nb=2007&action=view&page=64&frame=2&anchor=04:45:07.685'>
ISL problem</a>.

 


<!-- Date: Mon Jan 22 06:05:12 2007 -->
While I was checking the ISL 'no data' block, there was  
<a href= 
'/cgi/elog/elog.pl?nb=2007&action=view&page=64&frame=2&anchor=04:55:14.374'> 
a spike</a> 
in losses which became normal within 2 mins, before ACE could 
intervene. The SciCo learned from MCR about the beam shift due to a separator (B7) trip. MCR decided to terminate the store a little 
later. The SciCo informed me of the situation.  
<!-- Author: Satyajit -->


<!-- Date: Mon Jan 22 06:20:26 2007 -->
Looks like my sleeplessness is taking its toll! What I have written 
as end-of-store in the previous postings is actually a procedure 
to recover the tripped separator and continue with the existing 
store.  
<!-- Author: Satyajit -->
<!-- Comment: Mon Jan 22 06;21;52 comment by...Satyajit -->
<pre>&lt;a href=
'/cgi/elog/elog.pl?nb=2007&action=view&page=64&frame=2&anchor=05:35:21.524'&gt;
Link to e-log entry&lt;/a&gt;.
</pre>

<!-- Comment: Mon Jan 22 06;22;34 comment by...Satyajit -->
<a href=
'/cgi/elog/elog.pl?nb=2007&action=view&page=64&frame=2&anchor=05:35:21.524'>
Link to e-log entry</a>.

<!-- Comment: Mon Jan 22 08;21;26 comment by...Satyajit -->
Ok, around 7:45 am they decided to end the store. <b>There will
be a 2-4 hrs access</b>.


<!-- Date: Mon Jan 22 09:31:49 2007 -->
<h3>Week Summary</h3><p> 
<h4>Monday</h4> 
<ul> 
 <li>Signal and noise bias scans were done.</li> 
</ul> 
 
<h4>Tuesday</h4> 
<ul> 
 <li>Store 5179 (211e30). b0fib04 was stuck in CONFIG due to a faulty init 
     readback.</li> 
 <li>Store 5179 ended due to an abort by a main bus power supply. Post-quench 
     checkout was fine.</li> 
 <li>Switched the ISL chiller to the default one.</li> 
 <li>Masked init readback of e301 and e052.</li> 
 <li>Store 5182 (192e30)</li> 
 <li>A resonance around 20:24</li> 
</ul> 
 
<h4>Wednesday</h4> 
<ul> 
 <li>Bias pinkies cleanup</li> 
 <li>Weird ISL/L00 alarm and trigger inhibit. PS #4 momentarily lost 
     communication and recovered before AutoHocker response.</li> 
 <li>Store 5183 (251e30).</li> 
 <li>Too many  bias pinkies at a time. Limits adjusted.</li> 
</ul> 
 
<h4>Thursday</h4> 
<ul> 
 <li>One hour access after Store 5183 termination. Quiet time study planned.</li> 
 <li>Mark/Sasha looked at the e0b4 ladder for dropping readouts. 
     z-side was chopped off. The ladder e052 looses 1st chip in ~20% of cases. 
     Decided to living with it for the time being.</li> 
 <li>TurboHRR tests fine.</li> 
 <li>SVXINTER connected to TevMon permit. Still in testing phase. There seems 
     to be a bug in C:LOSTP RMS reporting.</li> 
 <li>Store 5186 (270e30, A new record!)</li> 
 <li>e0b4 shows AVDD2-like problem. IMON limits adjusted.</li> 
</ul> 
 
<h4>Friday</h4> 
<ul> 
 <li>The ladders e480 and e031 were repaired for dropping DVDD. 
     They are fine now.</li> 
 <li>Store 5089</li> 
 <li>Mark/Sasha diagnoses the problem with z-side of e0b4 to be due to a jumper 
     failure. Rdriver setting of 7 gets rid of readout problem. Revisit 13 ticks 
     of ghostbuster?</li> 
 <li>Store 5187 (225e30).</li> 
</ul> 
 
<h4>Saturday</h4> 
<ul> 
 <li>All yellow in SVXMon, including the ISL FIB f320. In case of the latter the 
     HDIs are missing and VRB goes into WYSIWYG mode.</li> 
 <li>Spontaneous switch-off of CAEN crate #13</li> 
 <li>Like e0b4, e380 shows a dropped readout problem. Rdriver=7 may solve 
     this.</li> 
 <li>D-mode calibrations taken. Bad</li> 
 <li>IMON version cleanup. imon_dev is a link pointing to  
     ~svxii/imon_dev_Jan08_2007. The previous version is renamed as 
     imon_2006.</li> 
</ul> 
 
<h4>Sunday</h4> 
<ul> 
 <li>Store 5188 (63.3e30). Low lumi. due to poor pbar transfer 
     efficiencies from the recycler.</li> 
 <li>The f020 ladder is getting worse. Would hit soft trip limit soon.</li> 
 <li>Another D-mode calibration taken. Good.</li> 
 <li>PS crate 14 spontaneous turn OFF. b0svx02 in stuck state.</li> 
</ul> 
 
<h4>Monday</h4> 
<ul> 
  <li>Store 5190, (109.95E30)</li> 
  <li>Paged for a yellow block in f320. CO had not noticed it since the  
      beginning of the Run. While I checked the RootFileBrowser and decided 
      for a new Run, the store was to be terminated.</li> 
</ul> 
 
<p>  
<!-- Author: Satyajit -->