<!-- Title: 10:22:41  Mon Jan  2 2006 -->
<!-- Crewchief: Ulrich (Main Pager) -->
<!-- Op1: Sebastian (SPL) -->
<!-- Op2: &nbsp; -->
<!-- Op3: &nbsp; -->
<!-- Op4: &nbsp; -->
<!-- Op5: &nbsp; -->
<!-- Op6: &nbsp; -->
<!-- Notes: -->
The women's national football team is already world champion, and I don't see a reason why men shouldn't achieve the the same as women.


<!-- Date: Mon Jan 2 10:23:51 2006 -->
<h3>Silicon Cafe cleanup</h3> 
We started the new year by cleaning up the desks in the Silicon Cafe.
<!-- Author: Mark, Sebastian, Ulrich -->


<!-- Date: Mon Jan 2 11:25:14 2006 -->
<h3>Online account required for Main Pager Carriers</h3> 
In order to log into our crates via 'vxcom' (the replacement for 'minicom', which ran only on b0dap10), you need an account on the online cluster. Logging in from svxii does not do the trick. The web page to be filled for the account request can be found <a href="http://b0www.fnal.gov/internal/sys/support/account.html">here</a>. They promise to process the request within 5 business days. I don't know if there is anything else apart from 'vxcom' which requires an online account.
<!-- Author: Ulrich -->
<!-- Comment: Mon Jan  2 11;36;06 comment by...sebastian -->
I already talked to Bill B about this, he has been trying to get the kerberized authentication for svxii to work, but did not succeed yet.


<!-- Date: Mon Jan 2 11:48:37 2006 -->
<br> 
<b>Follow up on L00 trips and PC status</b><br> 
<a href= 
'http://www-cdfonline.fnal.gov/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=281&frame=2&anchor=05:29:26'> 
Here</a> Mark mentions a trip of LB1W3 after the PS12 losses communicatio to svxinter. To me it looks similar to the PS7 situation, where one has to to be sure that the PC is off to power back the wedge, in this case they tried three times, but no need to hockerize the crate (note that last week only a couple of hockerizations were performed, much less than the week previous to last): 
<pre> 
First the crate losses it: 
New time 17953 Mon Jan  2 04:59:13 2006 
170 -1      0     0.00     0.00 LB1W3L2 VBIAS0 
171 -1      0     0.00     0.00 LB1W3L1 DVDD 
172 -1      0     0.00     0.00 LB1W3L1 AVDD 
173 -1      0     0.00     0.00 LB1W3L1 VBIAS0 
174 -1      0     0.00     0.00 LB1W3L0 DVDD 
175 -1      0     0.00     0.00 LB1W3L0 AVDD 
176 -1      0     0.00     0.00 LB1W3L0 VBIAS0 
177 -1      0     0.00     0.00 LB1W3PC 2VDOIM 
178 -1      0     0.00     0.00 LB1W3PC 5VDOIM 
Then comes back OFF: 
New time 18353 Mon Jan 2 05:05:53 2006 
165  1      3     0.12     4.00 LB1W3L3 DVDD 
166  1      3     0.00     5.00 LB1W3L3 AVDD 
168  1      3     0.12     2.00 LB1W3L2 DVDD 
171  1      1     0.12     1.00 LB1W3L1 DVDD 
174  1      1     0.12     4.00 LB1W3L0 DVDD 
177  1      3     1.19     0.00 LB1W3PC 2VDOIM 
178  1      3     1.72     0.00 LB1W3PC 5VDOIM 
Then the aces try to bring it back, it trips, but the PC stays on: 
New time 18870 Mon Jan 2 05:14:30 2006 
165  1   4099     0.56     1.00 LB1W3L3 DVDD 
168  1   4099     0.54     1.00 LB1W3L2 DVDD 
171  1      3     0.56     1.00 LB1W3L1 DVDD 
172  1      3     0.01     0.00 LB1W3L1 AVDD 
174  1      3     0.54     3.00 LB1W3L0 DVDD 
175  1      3     0.01     0.00 LB1W3L0 AVDD 
177  0 -32765     2.00   670.00 LB1W3PC 2VDOIM 
178  0 -32765     5.10  1335.00 LB1W3PC 5VDOIM 
New time 18878 Mon Jan 2 05:14:38 2006 
171  1      3     0.55     1.00 LB1W3L1 DVDD 
172  1      3     0.00     0.00 LB1W3L1 AVDD 
175  1      3     0.00     0.00 LB1W3L0 AVDD 
177  0 -32765     2.00   675.00 LB1W3PC 2VDOIM 
178  0 -32765     5.10  1340.00 LB1W3PC 5VDOIM 
The PC is turned OFF: 
New time 19067 Mon Jan 2 05:17:47 2006 
165  1   4099     0.12     3.00 LB1W3L3 DVDD 
168  1   4099     0.12     3.00 LB1W3L2 DVDD 
171  1      3     0.12     2.00 LB1W3L1 DVDD 
174  1      3     0.12     4.00 LB1W3L0 DVDD 
177  1      3     2.41     0.00 LB1W3PC 2VDOIM 
178  1      3     1.75     0.00 LB1W3PC 5VDOIM 
Now try to bring it up, but it trips again and the PC is still on: 
New time 19137 Mon Jan 2 05:18:57 2006 
165  1   4099     0.56     1.00 LB1W3L3 DVDD 
168  1   4099     0.54     2.00 LB1W3L2 DVDD 
171  1      3     0.57     1.00 LB1W3L1 DVDD 
172  1      3     0.05     0.00 LB1W3L1 AVDD 
174  1      3     0.55     2.00 LB1W3L0 DVDD 
175  1      3     0.05     0.00 LB1W3L0 AVDD 
177  0 -32765     2.00   670.00 LB1W3PC 2VDOIM 
178  0 -32765     5.09  1335.00 LB1W3PC 5VDOIM 
the third time it works, first OFF: 
New time 19211 Mon Jan 2 05:20:11 2006 
165  1   4099     0.12     3.00 LB1W3L3 DVDD 
168  1   4099     0.12     3.00 LB1W3L2 DVDD 
171  1      3     0.12     2.00 LB1W3L1 DVDD 
174  1      3     0.12     5.00 LB1W3L0 DVDD 
177  1      3     2.46     0.00 LB1W3PC 2VDOIM 
178  1      3     1.75     0.00 LB1W3PC 5VDOIM 
New time 19221 Mon Jan 2 05:20:21 2006 
171  1      3     0.12     3.00 LB1W3L1 DVDD 
177  1      3     2.36     0.00 LB1W3PC 2VDOIM 
The ON, this time all is OK: 
New time 19232 Mon Jan 2 05:20:32 2006 
171  2 -32765     0.12     2.00 LB1W3L1 DVDD 
177  0 -32765     2.24     0.00 LB1W3PC 2VDOIM 
New time 19242 Mon Jan 2 05:20:42 2006 
164  2 -32765     0.20     0.00 LB1W3L3 VBIAS1 
165  2 -32765     5.21    69.00 LB1W3L3 DVDD 
166  0 -32765     7.61   360.00 LB1W3L3 AVDD 
167  2 -32765     0.10     0.00 LB1W3L3 VBIAS0 
168  2 -32765     5.20    66.00 LB1W3L2 DVDD 
169  0 -32765     7.60   245.00 LB1W3L2 AVDD 
170  2 -32765     0.10     0.00 LB1W3L2 VBIAS0 
171  2 -32765     5.22    68.00 LB1W3L1 DVDD 
172  0 -32765     7.60   250.00 LB1W3L1 AVDD 
173  2 -32765     0.20     0.00 LB1W3L1 VBIAS0 
174  0 -32765     5.21    64.00 LB1W3L0 DVDD 
175  0 -32765     7.61   195.00 LB1W3L0 AVDD 
176  2 -32765     1.10     0.00 LB1W3L0 VBIAS0 
177  0 -32765     2.00   685.00 LB1W3PC 2VDOIM 
178  0 -32765     5.10  1385.00 LB1W3PC 5VDOIM 
</pre> 
The second column is the PS status (-1:no comm, 1:OFF, 0:ON, 2: STBY).
<!-- Author: Sebastian -->

<!-- Date: Mon Jan 2 14:06:58 2006 -->
Entered in Silicon database: <ul>
<li>Ladder: SB5W3L4 
<li>problem n: 1591 
<li>Status: needs_observation
<li>Type: Chip_capid
<li>Action: Monitoring
<li>entered by: boveia 
<li>description is: Chip 87 has the wrong cap ID for 100% of events since run 209484. 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B5W3&layer=L4">report</a></ul>
<!-- Author: Problem DB -->



<!-- Date: Mon Jan 2 15:35:29 2006 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-8094&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-8094  width='300' align='top'></a></td><td>This ladder (e263) saw a sudden jump in the bias current, which we could not correlated to anything else. The longer-term history of the ladder does not show anything like that. The bias current came down, but not (yet?) to the initial value.</td></tr></table>
<!-- Author: Ulrich -->


<!-- Date: Mon Jan 2 15:43:47 2006 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-8095&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-8095  width='300' align='top'></a></td><td>Here is the bias current history of e263. Nothing suspicious.</td></tr></table>
<!-- Author: Ulrich -->


<!-- Date: Mon Jan 2 15:48:36 2006 -->
<h3>Electron lens trip</h3> 
I happened to be in the control room when the electron lens tripped. The monitoring ace took silicon to standby. The SciCo called MCR: they suffered from a power supply failure in the electron lens. They are trying to replace the power supply.  
In the meanwhile, AGIGI2 climbs up (while all other losses are low). Let's hope MCR cleans it up when they are finished.
<!-- Author: Ulrich -->
<!-- Comment: Mon Jan  2 16;07;57 comment by...Ulrich -->
MCR seems to take longer, they have to call in an expert. I asked the shift crew to take data without silicon in the meanwhile. AGIGI2 is now about 10E9.

<!-- Comment: Mon Jan  2 16;29;08 comment by...Ulrich -->
The electron lens is back in business. Once AGIGI2 went below 5E9, I gave my ok to include the silicon again. Currently, AGIGI2 is still decreasing, it is now below 1.5E9.


<!-- Comment: Mon Jan  2 17;56;46 comment by...Ulrich -->
I forgot to mention that svxinter seems to have a strange time setting. The clock is shifted by -7 hours relative to CST. Is this done on purpose?
<!-- Comment: Mon Jan  2 18;21;04 comment by...Ulrich/Sebastian -->
<b>We recompiled the server code of svxinter to fix the time issue. We caused a heartbeat alarm and 
then the gui failed to load the powerset.dat file, because the link was pointing to a file 1min
ahead of the actual existing file.</b>


<!-- Date: Mon Jan 2 16:31:36 2006 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-8097&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-8097  width='300' align='top'></a></td><td>We had the silicon unbiased for a while now due to electron lens problems. However, when we switched it on again, e263 started to jump around again. We will keep an eye on it and check if it delivers proper data.</td></tr></table>
<!-- Author: Ulrich -->
<!-- Comment: Mon Jan  2 17;27;01 comment by...Ulrich -->
The only hint I could find in last year's e-log is 
<a href=
'http://www-cdfonline.fnal.gov/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=232&frame=2&anchor=11:36:32'>
this entry by Jen</a>. At that time the jump in bias current was related to an HRR due to a L2 decision timeout. This time, I cannot find any such correlation.
While I write this, the bias current jumps up and down happily, now reaching again 0.8 mA. 


<!-- Comment: Tue Jan  3 16;44;43 comment by...sasha -->
After PS5 was hockerized, bias on e263 went back to normal (see <a href=
'http://www-cdfonline.fnal.gov/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=282&frame=2&anchor=16:42:55'>
here </a>)
<!-- Date: Mon Jan 2 17:32:43 2006 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-8099&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-8099  width='300' align='top'></a></td><td>Another pinkie, in the bias current 0 of f101. This time, it was only a short fluctuation above the limit. We may have to bump up the limit (110 μA) in the future.</td></tr></table>
<!-- Author: Ulrich -->
<!-- Comment: Mon Jan  2 17;51;30 comment by...Ulrich -->
I decided to change the IMON limit for Ibias0 to 115 μA right away, as the value just jumped over the old limit.
<!-- Date: Mon Jan 2 17:50:13 2006 -->
Entered in Silicon database: <ul>
<li>Ladder: IB1W0L1 
<li>problem n: 1559 
<li>Status: needs_observation
<li>Type: BIAS
<li>Action: IMON_limits
<li>entered by: husemann 
<li>description is: Bumped up IMON limits for bias line 0 of f101. Strange: the problem DB claims that the old limit was bumped up from 100 to 150 μA, Instead I find a limit of 110 μA. Anyway, I increase it to 115 μA.<table border=1>
<tr><th>IMON LIMITS</th><th>Old</th><th>New</th></tr>
<tr><td><b>Nominal</b></td><td>86.721</td><td>86.721</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>115.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: Mon Jan 2 18:19:54 2006 -->
<center><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-8100&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-8100' width='300'></a><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-8101&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-8101' width='300'></a></center>
<!-- Author: Ulrich -->
<!-- Comment: Mon Jan  2 18;20;38 comment by...Ulrich H. -->
At least the ADC distributions for e263 look ok.



<!-- Date: Mon Jan 2 18:58:16 2006 -->
<b>We set up a new PC for SRC firmware development.</b> This is the third PC that can be used for this, though we only have a single license dongle.
<!-- Author: Satyajit/Sebastian -->


<!-- Date: Tue Jan 3 02:34:30 2006 -->
Got paged because the electron lens tripped again. The aces put silicon to standby, and within a minute, the electron lens came back. Now they were asking for permission to switch on silicon again. The electron lens just got a new power supply yesterday afternoon, and MCR is confident it was just a single trip of that supply. So I gave my ok to include silicon again.
<!-- Author: Ulrich -->
<!-- Comment: Tue Jan  3 07;41;09 comment by...Ulrich -->
Here is the 
<a href=
'http://www-cdfonline.fnal.gov/cgi/elog/elog.pl?nb=2006&action=view&page=7&frame=2&anchor=02:31:21.729'>
entry in the main e-log</a>. Note that the electron lens is not as stable as it was before MCR replace the power supply yesterday afternoon. Shortly after this incident, the lens current dropped from approx. 12 mA to approx 10.5 mA, and AGIGI2 increased to about 4.5E9. This is something to attack today.


<!-- Comment: Tue Jan  3 08;31;52 comment by...Ulrich -->
And another trip of the electron lens. The aces took silicon to standby, and the trip was recovered in a minute. AGIGI2 came back to the old value of 4.5E9. Once again I gave my permission to bias the silicon, but we will have to have a very close eye at things!
<!-- Comment: Tue Jan  3 09;35;22 comment by...Ulrich -->
I found some news about the electron lens from MCR in the
<a href=
'http://www-cdfonline.fnal.gov/cgi/elog/elog.pl?nb=2006&action=view&page=8&frame=2&anchor=09:12:22.988'>
main e-log</a>. Unless we decide otherwise, I will stick to our policy to take silicon to standby whenever the electron lens trips.
<!-- Date: Tue Jan 3 07:45:23 2006 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-8102&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-8102  width='300' align='top'></a></td><td>Another pinkie: bias line 0 of IB2W1L4. This problem has been spotted twice yesterday evening, <a href= 
'http://www-cdfonline.fnal.gov/cgi/elog/elog.pl?nb=2006&action=view&page=6&frame=2&anchor=22:15:17.069'> 
here</a> and  
<a href= 
'http://www-cdfonline.fnal.gov/cgi/elog/elog.pl?nb=2006&action=view&page=6&frame=2&anchor=23:49:38.405'> 
here</a>. I will bump up the limits later. 
</td></tr></table>
<!-- Author: Ulrich -->



<!-- Date: Tue Jan 3 09:18:31 2006 -->
<h3>SVX/L00 Air Separator Level</h3> 
I have spoken with Bill Noe about the SVX chiller air separator level. It had dropped below the warning limit of 17" lately. Bill promised to contact Stefano Moccia and to work on the problem.
<!-- Author: Ulrich -->


<!-- Date: Tue Jan 3 09:31:37 2006 -->
<h3>Reminder: Relative Humidity Sensors</h3> 
This is to remind ourselves (especially: me) about the outstanding issue of the RH sensors. We observed that <a href= 
'http://www-cdfonline.fnal.gov/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=263&frame=2&anchor=05:45:52'> 
one RH sensor died</a> (conjecture: radiation damage) in late August. We took it out of the interlock system. Another sensor which was already damaged (i.e. showed negative RH values) was swapped out for a spare sensor during a bore access. There is a couple of things left to do: 
<ul> 
<li>Check the long-term behavior of the RH sensors: <br> 
I did that today and observed that the SVX RH sensor (SVX_RH_DETE1) showed increasingly negative RH values, starting from October 2005. This guy is the next to die.</li> 
<li>Contact Honeywell about this failure mode: <br> 
We tried to contact Honeywell with the help of Marcel's father. They would never come back to us.</li> 
<li>Order spare RH sensors:<br> 
Willis gave his o.k. to order new sensors, but we did not follow up on the order yet.</li> 
</ul>  
<!-- Author: Ulrich -->



<!-- Date: Tue Jan 3 10:11:38 2006 -->
Forgot pager and cell at home. To get hold of me today call me at 3102379.
<!-- Author: Sebastian -->

<!-- Date: Tue Jan 3 15:55:40 2006 -->
<p><font size=+1> D-mode Calibration Job Started </font>
<p><pre>
Test of sendmail from D-mode calibration framework on cdffarm0</pre>
<!-- Author: CDF silicon D-mode calibration job server v1.4 -->
<!-- Comment: Tue Jan  3 17;25;36 comment by...Jason -->
Now that smtp.fnal.gov requires SMTP AUTH, you need to give the HELO on the sendmail socket before sending DATA.  (Before the SMTP AUTH was turned on, you could get away without sending the HELO.)  The e-log entries from D-mode should work now.
<!-- Date: Tue Jan 3 16:06:37 2006 -->
<h2> Access for e522 </h2> 
 
During the quiet time/access this afternoon, we took a look at e522, which started tripping on DVDD overcurrent on <a href= 
'/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=281&frame=2&anchor=14:23:07'> 
Sunday</a>, and had been out of the hardware database since then.  First we verified that e522 was still tripping.  Sebastian and Ulrich then made an access to swap the power supply cables for e52 and e53.  The trips stayed with the ladder, not the power supply, so this is an internal problem.  Since there is nothing we can do, we took e522 out of the database and will revisit it in the future.  
<!-- Author: Sebastian/Ulrich/Sasha/Mark -->
<!-- Comment: Tue Jan  3 16;12;05 comment by...s -->
and thanks to Rong for the input.
<!-- Comment: Tue Jan  3 16;13;33 comment by...s -->
Also note that there are some problems with the chip and cardEditor, I think that due to the new FS the chip editor does not pick up the changes done by the cardEditor, but this will have to be verified.
<!-- Comment: Wed Jan  4 13;05;26 comment by...Sebastian -->
the chipEditor problem is fixed, see <a href=
'http://www-cdfonline.fnal.gov/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=282&frame=2&anchor=13:01:09'>
this</a> link.
<!-- Date: Tue Jan 3 16:09:18 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: Made access to swap power supply cables with e53.  The trips stayed with the ladder, so this is an internal problem.  Should be revisited in the future to see if the problem fixes itself. 
<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 3 16:15:00 2006 -->
<pre>Investigation of e372. 
 
This ladder e372 was giving CAP_ID errors some time before and we were not able to reproduce the error with SVXDAQ. Then, Mark finally managed to reproduce errors on 12/27/05. He did a VRB reset that time. After the reset, errors went away for some period of time and reappeared again only in the last runs. We investigated this ladder again during today's access. Here is a result of studies: 
1) ran SVXDAQ in RA mode-- saw CAP_ID errors on chip89; 
2) reseted VRB and ran RA mode -- no errors; 
   NN mode -- errors; 
3) reseted VRB again and ran NN mode -- no errors. 
So, the problem seems to be related to VRB in a very non-obvious way.</pre>
<!-- Author: sasha/mark/sebastian/ulrich -->
<!-- Comment: Tue Jan  3 18;41;40 comment by...Ulrich/Sebastian -->
We swapped the VRB (out: SN183, in SN459).
<!-- Date: Tue Jan 3 16:42:55 2006 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-8103&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-8104  width='300' align='top'></a></td><td>Bias on e263 after hockerizing PS5.</td></tr></table>
<!-- Author: sasha -->
<!-- Comment: Tue Jan  3 16;54;33 comment by...Sebastian -->
Not sure if this fixed the problem, but since the data (which was checked by Antonio) looked fine, the problem with the vbias of this guy (see <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'>
here</a>) could have been that the readback was screwed up. We will see.



<!-- Date: Tue Jan 3 19:25:13 2006 -->
 
<h3>Problems with the silcion DB?</h3> 
 
Looks like RC does not read the new DB... is it possible that 
a RC session not started as cdfdaq will not pick up 
changes in the DB (in the new are)? I sent this questio nto Bill B.<br> 
 
Specifically I took e522 out of the database (using traceSilicon from the cdfprod account) and the PSGui picked up the changes (in the new area), 
but RC would still think that the ladder was integrated. I had to run traceSilicon 
with the old setup (the old traceSilicon, which writes to the old area) to get RC to ignore this ladder.<br> 
Also note that for the moment romoving ladders out of the database has to be done by me.<br>
<!-- Author: Sebastian -->


<!-- Date: Tue Jan 3 19:27:51 2006 -->
<h3>Code upgrade</h3> 
 
 
Upgraded svxdaq to the new version, so <b>setup_jeff</b> will now give you the new svxdaq. To get the old one you have to source setup_jeff.OLD. I updated svxdaq, the FFO display looks good now. 
There are still a few issues, but we tested the code today and looks fairly stable. Let me know if you have problems with it.<br>
<!-- Author: Sebastian -->


<!-- Date: Wed Jan 4 07:49:14 2006 -->
<h3>Refill of Coolant for SVX Chiller</h3> 
Stefano Moccia and Jim Loskot will refill coolant to the SVX chiller reservoir today (after 9:00) to fix the  
<a href= 
'http://www-cdfonline.fnal.gov/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=282&frame=2&anchor=09:18:31'>low air separator level</a>. 
 As there is a non-zero chance 
of a trip, we will have to coordinate this with the rest of our work.
<!-- Author: Ulrich -->
<!-- Comment: Wed Jan  4 15;13;54 comment by...Ulrich -->
Stefano and Jim finished their work around 14:00. They were cautious enough to refill the coolant (at room temperature) slowly and did not cause any trip. There was only a transient iFix warning for high SVX temperatures.
<!-- Date: Wed Jan 4 09:44:38 2006 -->
The 1RR21H crates (b0svx04 and 05) were power cycled to work 
on the power supplies (see <a href= 
'http://www-cdfonline.fnal.gov/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=281&frame=2&anchor=12:22:11'> 
here</a>). Dervin is done, the PS monitoring should not be ignored now . The VRBs are all in sync, coldstarted OK.
<!-- Author: Sebastian -->


<!-- Date: Wed Jan 4 12:59:14 2006 -->
There is no mouse at the FCC test stand. Has somebody borrowed it?
<!-- Author: Tuula -->


<!-- Date: Wed Jan 4 13:01:09 2006 -->
<table border=0><td><tr><td bgcolor=#e0e030>Fixed problem (see <a href= 
'http://www-cdfonline.fnal.gov/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=282&frame=2&anchor=16:06:37'> 
here</a>) with chipEditor in the new FS. The java class is not compiled by default, so it was missing. Now both the cardEditor and svxii.configure (aka chipEditor) work in the new FS. Let me know if you have problems with these.</td></tr></td></table>
<!-- Author: Sebastian -->



<!-- Date: Wed Jan 4 13:22:58 2006 -->
<h3>b0dasvx01 is now using the new FS</h3> 
Put a nasty kludge for the products problem. Everything seems to 
be working fine (svxdaq, PSGui, card/chip Editors). traceSilicon has to wait till I move the PSGui configuration files to a different area (not the code area - this was a bad idea to begin with, so it is a good change to fix it... and make the online sysadmins happy too).<br>
<!-- Author: Sebastian -->



<!-- Date: Wed Jan 4 16:04:09 2006 -->
<h3>Big problems...</h3> 
With Marcel's help we were trying to recover e522, but failed. While doing this we had a (most likely) unrelated trip of f03. It trips inmediatly on 5VDOIM overcurrent. This is the guy which we had to kludge the backplane pin... I am trying to request an access to look at the PS. Jen is ready. 
<!-- Author: Sebastian -->


<!-- Date: Wed Jan 4 16:05:18 2006 -->
With Bill, we upgraded the FE cpu kernel of all the fib and vrb crates. Everything looks fine this far.
<!-- Author: Sebastian -->


<!-- Date: Wed Jan 4 18:36:02 2006 -->
<h3>Access for IB0W3</h3> 
5V DOIM for IB0W3 began spontaneously tripping on Overcurrent today, so we went down to check it out.  This is the supply with a modified backplane pin; solder was added to make the pin thicker, so it could make a connection in a disformed backplane socket.  When the pin is not connected, we expect that the CAEN crate can no longer "see" the supply there.  We tried pulling the supply out a couple of times and straightening this pin, but it had no effect.<br> 
We also tried swapping cables with the supplies on both sides of IB0W3.  When f03 was hooked up to the supply for IB1W5, the DOIMs turned on without any problems, so wedge and cable connections look fine.  However, when f15 and f14 were hooked up to the supply for IB0W3, the 5V DOIM continued to trip (it listed an Overcurrent trip for f14 and a External Trip on both DOIMs for f15).  I even tried increasing the 5V DOIM current limit, from 1780 up to 1900; it still tripped Overcurrent.<br> 
For now we've pulled the IB0W3 supply out and taken the wedge out of the DB.  It looks like the problem is not with the modified pin, but instead a supply failure.  We'll need more time, and a talk tomorrow with the guys at FCC, to confirm this diagnosis and figure out what comes next.<br>
<!-- Author: Jen, Sebastian, Ulrich -->


<!-- Date: Thu Jan 5 08:28:25 2006 -->
We have tested VRB #147 with 82,936,000 loops (3,220,570 MBytes) and no errors. We declare this VRB (which was sitting in the teststand with a label "bad channel 8") a good spare.
<!-- Author: Tuula, Sebastian, Ulrich -->
<!-- Comment: Thu Jan  5 08;42;42 comment by...U/S -->
Note that VRB SN152 seems to be difficult to seat in the crate. Yesterday we were getting errors as soon as we tried to talk to it, but today is seems to be working fine. Right now its running the High speed test.


<!-- Date: Thu Jan 5 12:00:38 2006 -->
<h3>Problem with L00 Power Supply</h3> 
Marcel spotted this morning that the power supply channel for LB1W3L3 was showing a bias voltage 1 around 20 V while in standby. Our first attempt was to hockerize the power supply (#12)—not successful. A second hockerization did not help, so we decided to look into the supply in a controlled access. Currently, Jen and Sebastian are in the collision hall. We are granted access until 13:00, thanks to Marcel's good connections...
<!-- Author: Jen, Sebastian, Marcel, Ulrich -->
<!-- Comment: Thu Jan  5 13;17;34 comment by...Jen, Sebastian, Marcel, Ulrich -->
<h3> Access for LB1W3</h3>
Out of the blue, VBIAS31 had what looked like a monitoring problem: at standby (2V), the readback was 24V.  However, hockerizing didn't help.  We first tried turning the crate off and reseating the power supply - no change.  We then measured the output voltage from the back of the supply with the bias buddy for various voltage settings - for anything below 20V, the CAEN crate read ~24V and the bias buddy saw 0V.  Above 20V, the CAEN crate read perfectly (eg 30V set, CAEN measured 29.9V) but the bias buddy would read slightly lower values (eg 30V set, 22V read out after crowbar).  And it tripped Undervoltage when we tried to go above 40V (full bias voltage is 120V).<br>
To determine if the problem was with the supply or the crate/slot, we switched this supply with its neighbor, LB1W2.  With the two SUPPLIES swapped (not cables, supplies), we saw the same problems on the LB1W3 power supply when it was sitting in the LB1W2 slot and powering LB1W2.  With the LB1W2 supply in the LB1W3 slot, we couldn't turn it on b/c the 2V DOIM tripped Overcurrent.<br>
This told us clearly it was the supply that had gone bad.  We had one spare L00 supply, which had a history of tripping Overcurrent on DVDD3, but I hadn't been able to reproduce that problem on the teststand.  So we decided to swap it in - worst case scenario is that it starts tripping on DVDD3 again and we have to take out L3, which is exactly what we'd have to do if we left the old supply in anyway.  We didn't have time to do a loadbox test, so we just swapped the supply in.  So far, everything is working, no trips and none of the monitoring/UnV trips we saw on the other supply.<br>
It's also worth noting that LB1W3 is the supply we swapped in less than two months ago... for tripping Undervoltage on L3.<br>


<!-- Date: Thu Jan 5 15:57:59 2006 -->
Another VRB tested: #152 does not show errors after about 600,000 MBytes. We declare it a good spare and leave it in the teststand. Note that this VRB had issues with its startup when we tried to seat it yesterday. Today everything went fine.
<!-- Author: Sebastian, Mark, Ulrich -->


<!-- Date: Thu Jan 5 16:18:37 2006 -->
We have updated tstsvx1 to look at the new boot host, b0server02.  It rebooted fine.
<!-- Author: Sebastian,Ulrich,Mark -->

<!-- Date: Thu Jan 5 16:29:49 2006 -->
Entered in Silicon database: <ul>
<li>Ladder: LB1W3L0 
<li>problem n: 1581 
<li>Status: needs_observation
<li>Type: AVDD
<li>Action: IMON_limits
<li>entered by: husemann 
<li>description is: After a power supply swap, the AVDD limits have to be adjusted.<table border=1>
<tr><th>IMON LIMITS</th><th>Old</th><th>New</th></tr>
<tr><td><b>Nominal</b></td><td>195.0</td><td>180.0</td></tr>
<tr><td><b>Lower</b></td><td>190.0</td><td>175.0</td></tr>
<tr><td><b>Upper</b></td><td>200.0</td><td>185.0</td></tr></table> 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=L00&wedge=B1W3&layer=L0">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Thu Jan 5 16:33:05 2006 -->
Entered in Silicon database: <ul>
<li>Ladder: LB1W3L1 
<li>problem n: 1582 
<li>Status: needs_observation
<li>Type: AVDD
<li>Action: IMON_limits
<li>entered by: husemann 
<li>description is: After a power supply swap, we adjust the AVDD limits<table border=1>
<tr><th>IMON LIMITS</th><th>Old</th><th>New</th></tr>
<tr><td><b>Nominal</b></td><td>185.0</td><td>170.0</td></tr>
<tr><td><b>Lower</b></td><td>180.0</td><td>165.0</td></tr>
<tr><td><b>Upper</b></td><td>190.0</td><td>175.0</td></tr></table> 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=L00&wedge=B1W3&layer=L1">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Thu Jan 5 16:38:06 2006 -->
Entered in Silicon database: <ul>
<li>Ladder: LB1W3L2 
<li>problem n: 1593 
<li>Status: needs_observation
<li>Type: AVDD
<li>Action: IMON_limits
<li>entered by: husemann 
<li>description is: After a power supply swap, we update the IMON limits for AVDD.<table border=1>
<tr><th>IMON LIMITS</th><th>Old</th><th>New</th></tr>
<tr><td><b>Nominal</b></td><td>177.5</td><td>160.0</td></tr>
<tr><td><b>Lower</b></td><td>175.0</td><td>157.5</td></tr>
<tr><td><b>Upper</b></td><td>180.0</td><td>162.5</td></tr></table> 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=L00&wedge=B1W3&layer=L2">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Thu Jan 5 16:41:27 2006 -->
Entered in Silicon database: <ul>
<li>Ladder: LB1W3L2 
<li>problem n: 1593 
<li>Status: needs_observation
<li>Type: DVDD
<li>Action: IMON_limits
<li>entered by: husemann 
<li>description is: Adjusting DVDD limits after power supply swap.<table border=1>
<tr><th>IMON LIMITS</th><th>Old</th><th>New</th></tr>
<tr><td><b>Nominal</b></td><td>67.7871</td><td>55.0</td></tr>
<tr><td><b>Lower</b></td><td>60.0</td><td>50.0</td></tr>
<tr><td><b>Upper</b></td><td>80.0</td><td>70.0</td></tr></table> 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=L00&wedge=B1W3&layer=L2">report</a></ul>
<!-- Author: Problem DB -->



<!-- Date: Thu Jan 5 18:54:06 2006 -->
<h3>More on IB0W3 power supply</h3> 
This morning we tried putting the power supply into the trigger room teststand; we risked damaging one of the backplane connectors in the teststand, but we hoped to figure out if this was definitely a power supply problem.  We were lucky; even with the enlarged pin, the supply still fits into a normal backplane (we confirmed the backplane slot wasn't damaged by testing a normal supply in it afterwards); the solder on the enlarged pin was compressed somewhat to make it fit.  With the supply on the teststand we could not reproduce the 5V DOIM trips we saw in the collision hall.  This makes it less likely (although still not impossible) that the problem is a power supply failure.  It could be that the pin is still only making a flaky connection.<br> 
This afternoon we had a talk with Vince, and realized that at this point we don't know exactly what information is passed along through this pin; if the connection is flaky, it may be that some information (such as the current limit for the 5V DOIM) aren't being passed along, causing the trips we see.  We concluded the quickest and easiest first test is to put more solder on the pin and try it again.  If that doesn't work, we'll try more difficult solutions such as modifying another spare supply (in the hopes the problem somehow still lies with the supply but doesn't show up on the teststand) or designing a better connector for this screwed up pin.<br> 
The supply will modified tomorrow morning at FCC, with more solder on the pin, and we'll talk to Hank to see if he has a better idea of what information this particular connector passes along.  We'll try putting it in again on the next access opportunity.<br>
<!-- Author: Jen & Sebastian -->


<!-- Date: Thu Jan 5 21:50:58 2006 -->
<h4>Guess who's back in town</h4>
<!-- Author: Ankush -->
<!-- Comment: Fri Jan  6 04;54;19 comment by...early bird -->
Guess-who even "forgot" some shortbread in the silicon office. My breakfast...
<!-- Comment: Fri Jan  6 06;11;31 comment by...Cheeky -->
<p>ahem....that was no mistake.  It is an offering to the mighty Siliconeers !!</p>
<!-- Date: Fri Jan 6 04:21:44 2006 -->
A new record store is in. The initial CDF luminosity was 183.4e30. Again, we had an integrated dose alarm during the shot setup. Now losses are fine. As usual, the aces made the call to include the silicon but had a problem with VBIAS1 of IB1W5L2, which tripped on overcurrent. The current limit was 500 μA. When I arrived in the control room, I decided to temporarily bump up the limit to 700 μA to get the silicon up and running. I will investigate this rather large bias current later.
<!-- Author: Ulrich -->


<!-- Date: Fri Jan 6 04:26:34 2006 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-8105&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-8105  width='300' align='top'></a></td><td>History of bias current in IB1W5L2. This layer used to have an IMON limit of 100 μA. Maybe it is again a readback problem and hockerizing will bring this guy back to normal?</td></tr></table>
<!-- Author: Ulrich -->
<!-- Comment: Fri Jan  6 06;04;39 comment by...Ulrich -->
Hockerization did not help. We have to check if the data are ok.
<!-- Comment: Fri Jan  6 08;27;13 comment by...Ulrich -->
ADCmon plots for this ladder look fine.
<!-- Comment: Fri Jan  6 11;15;50 comment by...Sebastian & Ulrich -->
We have changed the bias current limit in the database from 500 μA to 700 μA to be consistent with the change performed in the GUI this morning. We also adjusted the IMON limits accordingly.
<!-- Date: Fri Jan 6 04:32:44 2006 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-8106&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-8106  width='300' align='top'></a></td><td>SVT SpyMon plot for store 4581. Everything looks ok.</td></tr></table>
<!-- Author: Ulrich -->


<!-- Date: Fri Jan 6 04:45:10 2006 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-8107&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-8107  width='300' align='top'></a></td><td>The bias current of e263 jumped up again. I will try a hockerization of this power supply as well.</td></tr></table>
<!-- Author: Ulrich -->
<!-- Comment: Fri Jan  6 06;04;50 comment by...Ulrich -->
Hockerization did not help. We have to check if the data are ok.



<!-- Comment: Fri Jan  6 08;26;56 comment by...Ulrich -->
ADCmon plots for this ladder look fine.
<!-- Date: Fri Jan 6 06:13:26 2006 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-8108&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-8108  width='300' align='top'></a></td><td>The 5V DOIM line of SB1W7 (SOC) has turned pink. Why was it turned on in the first place? — because I mistakenly turned it on after the hockerization. Doh. I switched it off again.</td></tr></table>
<!-- Author: Ulrich -->



<!-- Date: Fri Jan 6 11:12:13 2006 -->
Entered in Silicon database: <ul>
<li>Ladder: IB1W5L2 
<li>problem n: 374 
<li>Status: needs_observation
<li>Type: pinhole
<li>Action: IMON_limits
<li>entered by: husemann 
<li>description is: Seems that the same problem occured again. The bias current is approx. 630 μA. We change the limits in the hardware DB and in IMON accoringly.<table border=1>
<tr><th>IMON LIMITS</th><th>Old</th><th>New</th></tr>
<tr><td><b>Nominal</b></td><td>10.3142</td><td>628.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>700.0</td><td>700.0</td></tr></table> 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=ISL&wedge=B1W5&layer=L2">report</a></ul>
<!-- Author: Problem DB -->
<!-- Comment: Fri Jan  6 11;12;42 comment by...Ulrich -->
Sorry, the previous upper limit should read 100.



<!-- Date: Fri Jan 6 11:40:03 2006 -->
<h3>Integrated Dose Alarms: Some Data Mining</h3> 
 
<h4>General Remarks</h4> 
I have compared the integrated dose for stores with an without dose alarms. 
Here are some general findings: 
<ul> 
      <li>Qualitatively, the integrated dose as a function of time   
	around the "critical moment" looks very similar for all Tevatron  
	stores. 
      </li> 
      <li>The amount of integrated dose varies from store to store.  
	Stores without dose alarm before November 21 (big quench) were 
	well below the alarm limit. Stores without dose alarm after 
	December 12 were closer to the alarm limits. 
      </li> 
      <li>The integrated dose seems to be decreasing and was barely above 
	the alarm limits for the last two alarms. 
      </li> 
</ul> 
 
 
 
<h4>Dose Rate for Stores with Integrated Dose Alarms</h4> 
 
<table cellpadding='5' border='1'> 
      <tr> 
	<th>Store</th> 
	<th>Date</th> 
	<th>Dose Rate SVRAD0 (rad/min)</th> 
	<th>Dose Rate SVRAD1 (rad/min)</th> 
      </tr> 
      <tr> 
	<td>4553</td> 
	<td>12/16/05</td> 
	<td align='center'>20</td> 
	<td align='center'>20</td> 
      </tr> 
      <tr> 
	<td>4554</td> 
	<td>12/17/05</td> 
	<td align='center'>30</td> 
	<td align='center'>35</td> 
      </tr> 
      <tr> 
	<td>4555</td> 
	<td>12/18/05</td> 
	<td align='center'>40</td> 
	<td align='center'>30</td> 
      </tr> 
      <tr> 
	<td>4560</td> 
	<td>12/22/05</td> 
	<td align='center'>20</td> 
	<td align='center'>20</td> 
      </tr> 
      <tr> 
	<td>4569</td> 
	<td>12/27/05</td> 
	<td align='center'>25</td> 
	<td align='center'>25</td> 
      </tr> 
      <tr> 
	<td>4571</td> 
	<td>12/28/05</td> 
	<td align='center'>25</td> 
	<td align='center'>25</td> 
      </tr> 
      <tr> 
	<td>4574</td> 
	<td>12/31/05</td> 
	<td align='center'>20</td> 
	<td align='center'>below limit</td> 
      </tr> 
      <tr> 
	<td>4581</td> 
	<td>01/06/06</td> 
	<td align='center'>20</td> 
	<td align='center'>below limit</td> 
      </tr> 
</table> 
<h4>Dose Rate for Stores without Integrated Dose Alarms</h4> 
 
<table cellpadding='5' border='1'> 
      <tr> 
	<th>Store</th> 
	<th>Date</th> 
	<th>Dose Rate SVRAD0 (rad/min)</th> 
	<th>Dose Rate SVRAD1 (rad/min)</th> 
      </tr> 
      <tr> 
	<td>4480</td> 
	<td>11/02/05</td> 
	<td align='center'>10</td> 
	<td align='center'>10</td> 
      </tr> 
      <tr> 
	<td>4514</td> 
	<td>11/20/05</td> 
	<td align='center'>6</td> 
	<td align='center'>6</td> 
      </tr> 
      <tr> 
	<td>4573</td> 
	<td>12/30/05</td> 
	<td align='center'>12</td> 
	<td align='center'>12</td> 
      </tr> 
      <tr> 
	<td>4573</td> 
	<td>01/02/06</td> 
	<td align='center'>15</td> 
	<td align='center'>15</td> 
      </tr> 
    </table>
<!-- Author: Ulrich -->
<!-- Comment: Fri Jan  6 13;28;35 comment by...Sebastian -->
It was during store 4569 that the PS#1 turned itself off at the time of the alarm.
<!-- Date: Fri Jan 6 11:59:42 2006 -->
<h3>Crate #7: Spontaneous Switch-Off</h3> 
Crate #7 switched itself off spontaneously, and we switched it on again.
<!-- Author: Sebastian, Ankush, (Ulrich) -->



<!-- Date: Fri Jan 6 14:10:07 2006 -->
<h3>20+C+M+B+06 </h3> 
or better  
20+C+D+B+06   
<!-- Author: The three wise men  -->
<!-- Comment: Fri Jan  6 14;46;28 comment by...Brian&#039;s mother -->
What's the "D", 'detectorem'?


<!-- Date: Fri Jan 6 15:46:32 2006 -->
<br><b>Updates</b><br> 
<ul> 
<li>The f03 PS is back in the silicon office with an enlarged pin. 
The plan is to try again, and take pictures for plan B if it does not work. 
<li>Plan B is to route the PROM signal from the mainframe side of the crate. 
<li> The SVX PROM is in FCC to see if Vince can read it out. 
If he can not get the calibrations out of it we will have to send the supply back to CAEN (we don't have the calibration loads needed for a A509 supply at FCC). 
<li> The Malign Technologies LA is still sitting in from of the tstsvx1 crate. After some iterations with the support staff the situation  
now is that it does not find the adquisition card and freezes. 
I guess it came with a virus: M$. 
</ul>  
<!-- Author: Sebastian and all -->


<!-- Date: Fri Jan 6 17:32:50 2006 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-8109&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-8109  width='300' align='top'></a></td><td><h3>(Recent) Bias history for SB2W6L3 (e263)</h3> 
 
<p>The graph show a plot of e263 when it is biased. The current was small  
and stable until DS-Day 1827.6 (~14:26, 2 Jan 06). The bias  
current shoots up to 800uA and then settles to ~300uA after DS-Day 
1827.8 (19:12, 2 Jan 06).</p> 
 
<p>It is unlikely to be a pin hole as the current would be large 
and constant. So we need to think harder about what is  
actually causing this.</p></td></tr></table>
<!-- Author: Ankush -->


<!-- Date: Fri Jan 6 18:24:01 2006 -->
<h3>About the spy processes</h3> 
I recompiled the spy processes running on b0dasvx03 after changing the 
paths to the new file server. However the temperature spy is not running, it giver a strange error: 
<pre> 
time(&now); 
ttt = localtime(&now); 
tt1 = *ttt; 
c = ctime(&now); 
seconds_since_midnight=tt1.tm_hour*3600+tt1.tm_min*60+tt1.tm_sec; 
printf("time: %Y%m%d\n",ttt); 
 
time: %YResource temporarily unavailable1108560224 
</pre>  
The last line is the output when the code is ran. 
For now I will leave the process not running (but I stopped the email warning). 
<br>   
<!-- Author: Sebastian -->
<!-- Comment: Fri Jan  6 19;25;54 comment by...Ulrich -->
The above code doesn't appear to be clean C. I would suggest to use this:
<pre>
#include <time.h>
...
{
  time_t now;
  struct tm* ttt;
  char string[ 80 ];

  now = time( 0 );
  ttt = localtime( &now )

  // version 1
  strftime( buffer, 80, "time: %Y%m%d\n", ttt ); 
  fputs( buffer, stdout );

  // version 2
  printf( "time: %d:%d:%d", ttt->tm_year+1900, ttt->tm_month+1, ttt->tm_mday );
}
</pre>


<!-- Comment: Fri Jan  6 23;48;43 comment by...Sebastian -->
thanks, the problem was that I was using strftime with the wrong size (n). it is working now.
<!-- Date: Fri Jan 6 22:25:46 2006 -->
<h3>Pinkies</h3> 
Got paged because of a new pinkie in the bias line of e123. I will double-check and bump up the IMON limits tomorrow. 
<!-- Author: Ulrich -->
<!-- Comment: Fri Jan  6 22;26;55 comment by...Ulrich -->
Main e-log entry: <a href=
'http://www-cdfonline.fnal.gov/cgi/elog/elog.pl?nb=2006&action=view&page=18&frame=2&anchor=21:58:09.484'>
here</a>.



<!-- Date: Sat Jan 7 03:36:18 2006 -->
<h3>Crate 8 Hockerized</h3> 
Got paged because of a power supply crate communication failure in crate 8. The ace hockerized the crate and brought back the ladders fine. The page was only to let us know.
<!-- Author: Ulrich -->


<!-- Date: Sat Jan 7 08:47:58 2006 -->
Got paged about 7:20 due to several adjacent red cells in SVXMon which the shift crew could not recover by HRRing. See <a href= 
'http://www-cdfonline.fnal.gov/cgi/elog/elog.pl?nb=2006&action=view&page=19&frame=2&anchor=07:32:51.414'> 
this entry</a> in the main e-log. I suggested to start a new run, which solved the problem and caused only 3 minutes of downtime. Given the rather slow communication with the ace, I did not try to find out which FIB is affected and reboot the crate.  
<!-- Author: Ulrich -->

<!-- Date: Sat Jan 7 09:27:12 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: mhartz 
<li>description is: We studied this ladder again during quiet time on 1/3/05.  Since we seemed to be able to cure the capid errors (but only temporarily) by resetting the VRB, we decided to replace the VRB.  Since then it has been clean, so we should monitor to see if errors return. 
<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: Sat Jan 7 09:50:45 2006 -->
<h3>Another VRB Tested OK</h3> 
We have run the VRB we swapped out last week in the teststand (S/N 183). After 85,753,000 loops (3,329,960 MByte), no bit errors where detected. We will update the VRB database accordingly.
<!-- Author: Mark, Sebastian, Ulrich -->
<!-- Comment: Sat Jan  7 09;56;53 comment by...Ulrich -->
See <a href=
'http://www-cdfonline.fnal.gov/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=282&frame=2&anchor=16:15:00'>
this entry</a> for Mark's investigation of the VRB errors.


<!-- Date: Sat Jan 7 11:56:00 2006 -->
<h3>IB0W3 is back!</h3> 
During access today, we tried putting back the IB0W3 power supply with its newly enlarged pin.  The symptoms when cabled to the wedge were the same - it tripped Overcurrent on the 5V DOIM.  Then we tried cabling it up to the loadbox - everything worked perfectly when the supply was hooked up to the loadbox!  So then we decided to try bumping the current limits on the 5V DOIM.  The current limit was at 1780 mA; we went up in ~100 mA increments until it didn't trip anymore, at 2000 mA.  But then, the 2V DOIM started tripping Overcurrent instead.  So we bumped the limits on that one up; it was initially set to 850 mA, we had to put it all the way up to 1250 mA to keep it from tripping.<br> 
At this point we had the guys upstairs change the limit in the PSGui and try running the ladders from upstairs.  They found that it still tripped 5V DOIM Overcurrent when they tried running it while it was on, so we advised them to increase the current limit by 100 and try again.  This time I monitored the currents from the CAEN crate while they went from standby to on to running; at standby, 2V DOIM draws 1125 mA current, running it takes 1145 mA; the 5V DOIM takes 1990 at standby, 2010 running.<br> 
With the current current limits (1250 mA for the 2V DOIM, 2100 for the 5V DOIM) IB0W3 should be fine.  Ulrich will be here at the start of the next store to monitor it, and if it starts tripping Overcurrent again he will try bumping the limits up even farther (the ultimate limit is 5000 mA). So, the wedge should be back up and running for the next store!<br> 
The real question now is why the portcard currents changed so much, so suddenly.  We doubt it's related to the enlarged pin at all; it may have something to do with the power supply's current calibrations getting mixed up, or maybe for some reason the portcard really is drawing more current.  We'll continue trying to figure this out...<br> 
<!-- Author: Jen, Sebastian, Ankush, Ulrich -->
<!-- Comment: Sat Jan  7 12;02;31 comment by...Sebastian -->
Should say that <b>Jen</b> had the very good idea of taking the loadbox to the collision hall, which was the key of finding the problem.
<!-- Comment: Sat Jan  7 12;04;41 comment by...Sebastian -->
On the bad side we broke the protocol of controlled access when one of us went into the coll hall (just pass the door) to help move the equipment. This was an error on my part (Sebastian).
<!-- Comment: Sat Jan  7 12;56;46 comment by...Ankush -->
<p>All wedges for CAEN PS 3 (this includes IB0W3) has been biased for ~45minutes with no trips or other PS problems.</p>
<!-- Date: Sat Jan 7 12:01:18 2006 -->
Entered in Silicon database: <ul>
<li>Ladder: IB0W3All 
<li>problem n: 1523 
<li>Status: needs_observation
<li>Type: Wedgewide_other
<li>Action: PS_work
<li>entered by: jpursley 
<li>description is: Went down to try re-installing the wedge with an even more enlarged backplane pin; this didn't work.  Turns out that the current limits for the 5V DOIM and 2V DOIM needed to be increased by several hundred mA (2V DOIM from 850 up to 1250, 5V DOIM from 1780 up to 2100), and then the supply stopped tripping, and ran fine with SvxDaq.  We'll need to observe the next store, to make sure these limits are adequate when running with data too.  See <a href= 'http://www-cdfonline.fnal.gov/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=282&frame=2&anchor=11:56:00'>elog</a>. 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=ISL&wedge=B0W3&layer=All">report</a></ul>
<!-- Author: Problem DB -->




<!-- Date: Sat Jan 7 12:41:03 2006 -->
Entered in Silicon database: <ul>
<li>Ladder: SB1W2L4 
<li>problem n: 1243 
<li>Status: needs_observation
<li>Type: Chip_other
<li>Action: Diagnosis_update
<li>entered by: amitra 
<li>description is: <p>From the bit reporter, the errors for this ladder dissapeared after 2 Jan 06 by itself!!.  This was confirmed in SVXDAQ. No errors after 10,000 events in RA and NN mode.</p>  <p>Continue to observe this ladder for a week or so.  If it continues to run error-free then declare this thread fixed.</p> 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B1W2&layer=L4">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Sat Jan 7 12:56:27 2006 -->
Entered in Silicon database: <ul>
<li>Ladder: SB0W11L2 
<li>problem n: 1588 
<li>Status: needs_observation
<li>Type: VRB_channel
<li>Action: Diagnosis_update
<li>entered by: mhartz 
<li>description is: We swapped the VRB (b0svx00 slot 20) with the hope that it would fix the intermittent d0 errors.  There were no d0 errors in svxdaq after the swap (although there were capid and illegal channel errors).  The old VRB is being tested in the testand.  Should monitor to see if d0 errors are gone. 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B0W11&layer=L2">report</a></ul>
<!-- Author: Problem DB -->




<!-- Date: Sat Jan 7 13:21:53 2006 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-8110&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-8110  width='300' align='top'></a></td><td> </td></tr></table>
<!-- Author: Ankush -->
<!-- Comment: Sat Jan  7 13;27;58 comment by...Ankush -->
<h4>Bias history of SB1W2L3</h4>

<p>After DS-Day 1550 (March 31 2005) the Bias current fluctation became quite large and the bias current increased from ~100uA to 600uA.  However the current fluctuations from DS-Day ~1650 (9 July 2005) have  significantly reduced the the current is only increasing at a slow rate.</p>
<!-- Date: Sat Jan 7 13:22:32 2006 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-8111&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-8111  width='300' align='top'></a></td><td> </td></tr></table>
<!-- Author: Ankush -->
<!-- Comment: Sat Jan  7 13;30;29 comment by...Ankush -->
<h4>DVDD History of SB2W9L1</h4>

<p>After the pre-Xmas mini-shutdown (DS-Day>1800), the DVDD current fluctuations for SB2W9L1 (e291) have substantially increased and the 'mean' current seems to be going up.  At the moment the data from this ladder looks good.  But we need to establish whether this is a PS problem or a ladder problem.</p>
<!-- Date: Sat Jan 7 13:22:56 2006 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-8112&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-8112  width='300' align='top'></a></td><td> </td></tr></table>
<!-- Author: Ankush -->
<!-- Comment: Sat Jan  7 13;33;53 comment by...Ankush -->
<h4>Bias History of IB1W5L2</h4>

<p>The bias for this ladder gave a PINKY recently in IMON.  After the mini-shutdown (~DS-Day 1800), the Bias current came back a little higher than before the shutdown.  But the recent data shows it is going down.  Also the history shows this ladder has a tendancy to go up and then slowly come down.  So I believe the bias current for this ladder will come down in the next few weeks.</p>

<!-- Date: Sat Jan 7 13:24:17 2006 -->
e0b2 has been giving <a href= 
'/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=280&frame=2&anchor=11:09:27'> 
intermittent d0 errors</a> which seem to be temporarily fixed by VRB resets.  On the assumption that this was a VRB problem we swapped the VRB (b0svx00 slot 20).  The old VRB is currently running in the testand error free.  e0b2 does not give d0 errors in svxdaq.
<!-- Author: Ankush,Sebastian,Mark -->





<!-- Date: Sat Jan 7 13:37:45 2006 -->
<h3>More on the Spy processes</h3> 
 
Ok, after some struggle (see <a href= 
'http://www-cdfonline.fnal.gov/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=282&frame=2&anchor=18:24:01'> 
here</a>) all the spy processes are running and the paths are updated to the new areas. To check things, I have unmounted the old 
/cdf/code-common area from b0dasvx03, everything is fine, so svx03 will not longer mount the old fs.<br>
<!-- Author: Sebastian -->
<!-- Comment: Sat Jan  7 13;57;34 comment by...Sebastian -->
I have also unmounted the old FS from b0dasvx02. IMON looks fine.
Only b0dasvx01 to go (which is not using the old FS, but just in case we will do this machine on Monday in case there are probelms),
and then the <b>fileserver migration will be over</b>.<br>


<!-- Comment: Mon Jan  9 08;55;39 comment by...Sebastian -->
Unmounted the old FS from b0dasvx01, everything looks fine, but we should keep this in mind. If you have unusual problems with the tools (PSGui, cardEditor, etc) let me know. Note that <b>traceSilicon</b> still has to be fixed (will do it this week).
<table border=0><td><tr><td bgcolor=#e0e030>
This completes our FS migration.
</td></tr></td></table>
<!-- Date: Sat Jan 7 18:47:45 2006 -->
<h3>Store 4584</h3> 
Store 4584 came in with an initial luminosity of 158 x 10<sup>30</sup>cm<sup>-2</sup>s<sup>-1</sup>. All losses were fine, so the aces decided to include the silicon right away. Here is a couple of observations from my side: 
<ul> 
<li>This time, we had <em>no integrated dose alarm</em>. I have checked the ACNET plots. The largest dose rate per minute is around 12-15, i.e. below the alarm threshold.</li> 
<li>The currents for the +2V and the +5V DOIM lines of IB0W3 were very similar to what we observed during the coldstart running this morning: 1125-1145 (before/during data-taking) for +2V and 1980-2005 for +5V.</li> 
<li>When the silicon was ramped via the iFix GUI, IB0W3 stayed in standby. The monitoring ace realized this because the trigger inhibit from the ISL high voltage kicked in. My conjecture: something in iFix did not pick up the change when we re-included this wedge  into the hardware database. For my education: what is the mechanism for this? Ankush and I reloaded CAENvolts.dat in the PSGUI this morning. I restarted PSGUI, just to be sure that everything picks up the correct limits.</li> 
<li>SVXMon looks fine</li> 
</ul>
<!-- Author: Ulrich -->


<!-- Date: Sat Jan 7 18:49:39 2006 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-8113&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-8114  width='300' align='top'></a></td><td>SVTSpyMon shows no new holes in SVT. Everything looks as usual.</td></tr></table>
<!-- Author: Ulrich -->


<!-- Date: Sat Jan 7 18:56:25 2006 -->
<center><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-8115&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-8115' width='300'></a><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-8116&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-8116' width='300'></a></center>
<!-- Author: Ulrich -->
<!-- Comment: Sat Jan  7 18;59;16 comment by...Ulrich -->
Here are the ADCmon plots for e263, our persistent bias line pinkie. The ADC spectra have the same shape. However, the current run has significantly more entries with 0 ADC counts than the reference. Is this a problem or just low statistics?


<!-- Date: Sun Jan 8 09:35:08 2006 -->
The crate CPU of b0fib06 gets stuck upon rebooting, it gets to: 
<pre> 
Done executing startup script boot/front-end/startup.cdf 
Found CPU Type 70 with bus speed 60.000000 ns 
b0fib06-> UNIVERSE_U2SPEC addr   0xC14004 
</pre> 
And freezes. I am coming in.  
<!-- Author: Sebastian -->
<!-- Comment: Sun Jan  8 11;02;42 comment by...sebastian -->
Tried the following:<br>
<ul>
<li> re flashing prom (twice): no change (freezes on UNIVERSE_U2SPEC) - this after changing boot sequence...
<li> booting from my code: no change
<li> removing only: rc_SVX, svx_setClkSpeed, sp FER_dummy_setup:
boots, and then freezes if I spawn FER_dummy_setup
<li> power cycle the rack, still freezes on sp FER_dummy_setup
</ul>
<!-- Comment: Sun Jan  8 11;04;25 comment by...sebastian -->
freezes upon sp FER_dummy_setup...
<!-- Comment: Sun Jan  8 11;34;23 comment by...Ulrich -->
The only old entry about FER_dummy_setup I could find in the silicon e-log is from <a href=
'http://www-cdfonline.fnal.gov/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=138&frame=2&anchor=12:45:17'>
January 2003</a>
<!-- Comment: Sun Jan  8 13;24;19 comment by...mark/ulrich/sebastian -->
Low level VME reads to any board on the crate freezes the CPU. The theory is that the first fib to fail (fib06 slot 9) died some horrible death and is screwing up the backplane. We will swap the fib. 
<!-- Comment: Sun Jan  8 13;27;15 comment by...Sebastian, Mark, Ulrich -->
After some more investigation it seems clear to us that the crate freezes immediately after the CPU accesses any of the boards via the VME bus.
<p>
We called Marcel and asked him about the failure mode we are observing. He recalled two previous incidents, in which one of the Alteras on a FIB board died due to radiation. As a consequence, it drew a large current and blew the (7A) fuse of the board. In addition, the whole VME bus got stuck. We should be able to visually identify the broken board, since one of the 5V LEDs should be off. Swapping out the broken FIB board fixed the problem in the past. I found related entries in the silicon e-log in
<a href=
'http://www-cdfonline.fnal.gov/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=197&frame=2&anchor=11:43:21'>
May 2004</a>
and
<a href=
'http://www-cdfonline.fnal.gov/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=208&frame=2&anchor=01:01:48'>
August 2004</a>.

<p>
We requested a 1-hour access after the current store (probably late evening or early owl shift) to swap the broken FIB board (and, if needed, the crate CPU).
<!-- Date: Sun Jan 8 10:26:55 2006 -->
<h3>Problem with b0fib06</h3> 
Got paged because the aces could not recover a trip. They had problems communicating with the crate from PSGUI: 
<pre> 
Sun Jan 08 08:51:48 CST 2006     TRIP: SVX  B3  W7 DVDD0 OverCurrent 
Sun Jan 08 08:55:15 CST 2006     success: Resetting trips 
Sun Jan 08 09:00:28 CST 2006     ERROR: Channel0 SVX B3 W7 Handshake - No response from the FIB 
</pre> 
After another attempt of power-cycling the wedge, and the aces finally told me that there was an issue with b0fib06, I walked the DAQ ace through the necessary steps to get the FIB crate back in line. The crate was not pingable, so we tried to sheperd it - without success. At that point I instructed the ace to start a new run without silicon, called Sebastian (see entry above) and drove in. 
<p> 
In the control room, the DAQ ace and I  
<a href= 
'http://www-cdfonline.fnal.gov/cgi/elog/elog.pl?nb=2006&action=view&page=23&frame=2&anchor=09:20:44.273'> 
scanned through the log files<a> to look for correlations with DAQ problems and beam conditions. We found a whole bunch of reformatter errors, some resonances, and a spike in the losses (which may have been caused by a flying wire scan, which happened at the same time).  
<!-- Author: Ulrich -->


<!-- Date: Sun Jan 8 10:56:04 2006 -->
<h3>More Bias Line Pinkies: A Follow-Up</h3> 
Since yesterday, the aces discovered a couple of pinkies in ISL bias lines: 
<ul> 
<li><a href= 
'http://www-cdfonline.fnal.gov/cgi/elog/elog.pl?nb=2006&action=view&page=22&frame=2&anchor=00:09:04.033'> 
IB1W0L1 VBIAS1</a></li> 
<li><a href= 
'http://www-cdfonline.fnal.gov/cgi/elog/elog.pl?nb=2006&action=view&page=22&frame=2&anchor=05:59:30.076'> 
IB2W1L0 VBIAS1</a></li> 
<li><a href= 
'http://www-cdfonline.fnal.gov/cgi/elog/elog.pl?nb=2006&action=view&page=22&frame=2&anchor=00:09:04.033'> 
IB3W0L1 VBIAS0</a></li> 
<li><a href= 
'http://www-cdfonline.fnal.gov/cgi/elog/elog.pl?nb=2006&action=view&page=23&frame=2&anchor=08:52:16.755'> 
IB3W0L2 VBIAS0</a></li> 
</ul> 
The aces were nice enough to document the problems and not page me in the middle of the night.
<!-- Author: Ulrich -->


<!-- Date: Sun Jan 8 10:57:25 2006 -->
<center><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-8117&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-8117' width='300'></a><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-8118&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-8118' width='300'></a><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-8119&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-8119' width='300'></a><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-8120&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-8120' width='300'></a></center>
<!-- Author: Ulrich -->
<!-- Comment: Sun Jan  8 10;58;19 comment by...Ulrich -->
Here are the bias currents for the pink cells as a function of time. All of the show the usual increase in bias current due to radiation damage.






<!-- Date: Sun Jan 8 13:41:54 2006 -->
Entered in Silicon database: <ul>
<li>Ladder: IB1W0L1 
<li>problem n: 1559 
<li>Status: needs_observation
<li>Type: BIAS
<li>Action: IMON_limits
<li>entered by: husemann 
<li>description is: Now, also bias line 1 needs an adjustment of the current limit.<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>81.2587</td></tr>
<tr><td><b>Lower</b></td><td>0.5</td><td>0.5</td></tr>
<tr><td><b>Upper</b></td><td>105.0</td><td>110.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 8 13:43:50 2006 -->
Entered in Silicon database: <ul>
<li>Ladder: IB2W1L0 
<li>problem n: 1595 
<li>Status: needs_observation
<li>Type: BIAS
<li>Action: IMON_limits
<li>entered by: husemann 
<li>description is: Bumping up IMON limit for bias line 1.<table border=1>
<tr><th>IMON LIMITS</th><th>Old</th><th>New</th></tr>
<tr><td><b>Nominal</b></td><td>76.4828</td><td>76.4828</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>105.0</td></tr></table> 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=ISL&wedge=B2W1&layer=L0">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Sun Jan 8 13:50:08 2006 -->
Entered in Silicon database: <ul>
<li>Ladder: IB3W0L2 
<li>problem n: 1531 
<li>Status: needs_observation
<li>Type: BIAS
<li>Action: IMON_limits
<li>entered by: husemann 
<li>description is: Bumping up IMON limits for bias line 0.<table border=1>
<tr><th>IMON LIMITS</th><th>Old</th><th>New</th></tr>
<tr><td><b>Nominal</b></td><td>89.9302</td><td>89.9302</td></tr>
<tr><td><b>Lower</b></td><td>0.5</td><td>0.5</td></tr>
<tr><td><b>Upper</b></td><td>105.0</td><td>110.0</td></tr></table> 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=ISL&wedge=B3W0&layer=L2">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Sun Jan 8 14:36:14 2006 -->
Entered in Silicon database: <ul>
<li>Ladder: SB2W2L3 
<li>problem n: 436 
<li>Status: needs_urgent_monitoring
<li>Type: Chip_bit_error
<li>Action: Monitoring
<li>entered by: boveia 
<li>description is: Bit 5 low back for 3 runs since 209760.  If this does not go away again, give to Detector. 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B2W2&layer=L3">report</a></ul>
<!-- Author: Problem DB -->



<!-- Date: Sun Jan 8 23:17:23 2006 -->
<h3>Access Report: b0fib06</h3> 
Mark and Sebastian went in to swap the broken FIB board in b0fib06 after the FIB problem we encountered 
<a href= 
'http://www-cdfonline.fnal.gov/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=282&frame=2&anchor=09:35:08'> 
this morning</a>. 
They verified that only the board in slot 9 had the +2V LED off, switched off the crate and changed that board. After that, the crate booted up fine. Ankush and Ulrich powered up the wedges served by b0fib06 and took the system through coldstart. Everythink worked fine.
<!-- Author: Sebastian, Mark, Ankush, Ulrich -->
<!-- Comment: Sun Jan  8 23;29;16 comment by...s -->
Thanks to Marcel and the DAQ people for the input.


<!-- Date: Mon Jan 9 02:13:06 2006 -->
<h3>Store 4586</h3> 
Got paged for the new store 4586, with the following observations: 
<ul> 
<li>Aces had a question about the new TEL policy: should they wait even if AGIGI2 is above the warning limit. I told them to put the silicon to standby once AGIGI2 goes above 5e9.</li> 
<li>The store started with an initial luminosity of 167e30.</li> 
<li>In the first minutes, we had large proton losses, greater than 50 kHz. After a while, MCR brought the losses down below 10 kHz.</li> 
<li>At losses below 8 kHz, the shift crew decided to ramp up the silicon. Now we are running again with silicon.</li> 
</ul>
<!-- Author: Ulrich -->
<!-- Comment: Mon Jan  9 07;26;41 comment by...Ulrich -->
Also worth mentioning: no integrated dose alarm. I have checked the integrated dose during the shot. SVRAD0 and SVRAD1 were below the alarm limit, roughtly between 12 and 15 rad/min
<!-- Date: Mon Jan 9 02:20:22 2006 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-8121&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-8122  width='300' align='top'></a></td><td>SVT SpyMon plot looks fine.</td></tr></table>
<!-- Author: Ulrich -->


<!-- Date: Mon Jan 9 05:04:14 2006 -->
Got paged because Tevatron lost monitoring of the p and pbar losses. The shift crew asked for advice whether to leave the silicon biased under these conditions. They had called MCR which claimed the losses are still low. I suggested to ask MCR for their source of information about the losses or any other redundant source. If they manage to keep an eye on the losses, they should keep the silicon in.
<!-- Author: Ulrich -->


<!-- Date: Mon Jan 9 05:45:47 2006 -->
Got paged because of a  
<a href= 
'http://www-cdfonline.fnal.gov/cgi/elog/elog.pl?nb=2006&action=view&page=25&frame=2&anchor=05:22:30.222'> 
DVDD pinkie in SB4W1L4</a>. 
The DVDD current jumped up, probably around the time when they halted the run due to CLC problems. I asked for some way to take the silicon through 'config', and they suggested to end the current run (which was in halt for an hour already). With the next 'config', the pinkie went away. 
<p> 
Since the CLC problem seems not to be solved quickly, and the losses could not be monitored directly, the aces asked if they should put the silicon to standby. I found this a good idea and agreed.
<!-- Author: Ulrich -->



<!-- Date: Mon Jan 9 08:51:00 2006 -->
   <h3>Summary of the Week</h3> 
 
    Monday, January 2, 2006 
    <ul> 
      <li>e263: sudden jump in bias current, not yet understood, ADC spectra ok, currently ignored in IMON</li> 
      <li>Electron lens trips: several "soft" failures after a power supply swap. New policy: keep silicon biased if electron lens is off for a couple of minutes only (i.e. as long as the abort gap still clean enough)</li> 
      <li>Many resonances in a row: probably related to problem DAQ system, went away with new run</li> 
    </ul> 
 
    Tuesday, January 3, 2006 
    <ul> 
      <li>Access for e522: verified that problem is internal, not the power supply, ladder is still out of the database</li> 
      <li>VRB swap due to CAP_ID errors in e372</li> 
      <li>Work on fileserver move: so far, traceSilicon et al. work only as user 'cdfprod' 
    </ul> 
 
    Wednesday, January 4, 2006 
    <ul> 
      <li>Shot setup delayed due to Tevatron problems</li> 
      <li>Power supply in 1RR21H repaired</li> 
      <li>Refill of SVX chiller coolant: cures low air separator levels</li> 
      <li>Front-end crates are now booting the most recent kernel</li> 
      <li>Another try to recover e522, without success</li> 
      <li>IB0W3 trip on 5V DOIM, taken out power supply</li> 
    </ul> 
 
    Thursday, January 5, 2006 
    <ul> 
      <li>Power supply problem in LB1W3L3: showing bias voltage of 20 V in standby. Access to swap in spare supply: problem fixed.</li> 
      <li>Plan to fix IB0W3 power supply: enlarge pin</li> 
      <li>New record store 4581: integrated dose alarm, VBIAS1 trip in IB1W5L2 (had to increase bias current limit, Hockerization did not help) 
    </ul> 
 
    Friday, January 6, 2006 
    <ul> 
      <li>Crate #7: spontaneous switch-off</li> 
      <li>Crate #8: Hockerization</li> 
    </ul> 
 
    Saturday, January 7, 2006 
    <ul> 
      <li>Access to reinstall power supply for IB0W3: had to increase current limits for PC lines</li> 
      <li>Store 4584: no integrated dose alarm, everything fine</li> 
    </ul> 
 
    Sunday, January 8, 2006 
    <ul> 
      <li>Broken FIB board blocks VME bus of b0fib06: no silicon until end of store</li> 
      <li>Access to replace FIB board: successful</li> 
      <li>Store 4586: large proton losses, no integrated dose alarm, loss of loss monitoring</li> 
    </ul> 
 
    Miscellaneous 
    <ul> 
      <li>After the annealing period during the mini-shutdown in December, the bias currents for several ladders went above limits. Limits adjusted accordingly.</li> 
      <li>Two ladders (e263, f152): jumps in bias current</li> 
      <li>b0dasvx02, b0dasvx03 completely moved to new file server</li> 
    </ul>  
<!-- Author: Ulrich -->