<!-- Title: 10:27:57  Mon Oct 15 2007 -->
<!-- Crewchief: Oscar (MPC) -->
<!-- Op1: Jose (SPL) -->
<!-- Op2: &nbsp; -->
<!-- Op3: &nbsp; -->
<!-- Op4: &nbsp; -->
<!-- Op5: &nbsp; -->
<!-- Op6: &nbsp; -->
<!-- Notes: -->
<pre>MPCs striking back. Hoping to get some data.... next week.</pre>


<!-- Date: Mon Oct 15 12:42:10 2007 -->
During this morming access Techs replaced the fan pack on SVSET (b0fib05). The bypass has been taken out and no fan failure is present.
<!-- Author: Jose -->


<!-- Date: Mon Oct 15 14:08:55 2007 -->
<h3> PS work of the day</h3> 
In closing up the PS work of this shutdown we worked on two corners:<br> 
<li>North-East corner, bottom top PS crate (crate 15) we took LB1W0 out for repair. Then we moved module #8, incorrectly put in slot 7, to its rightful place in slot 9. Finally we have put module #02 to slot number 7 (LB1W4). The load box test was OK. </li> 
 
<li>North-West Rack, crate 7. We loadtested IB0W5 sucessfully. 
</li> 
 
All the modules were checked out sucessfully. 
We are only one module short of powering up the whole detector after the PS replacement/refurbishing that took place in this shutdown. 
 
 
 
<!-- Author: The PS crew -->
<!-- Comment: Tue Oct 16 12;56;48 comment by...The PS crew -->
Note that the module #24 @ IB0W5 is a <b>FORWARD-converted</b> one,
which requires <b>MODIFIED adapters</b> for operation. The module 
#30 @ IB0W3 is another of the same type we used during our shutdown
work.

<!-- Date: Mon Oct 15 15:23:38 2007 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-11894&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-11895  width='300' align='top'></a></td><td>DVDD current for e084</td></tr></table>
<!-- Author: sasha/hugo -->


<!-- Date: Mon Oct 15 15:28:03 2007 -->
End of PDB staudies for today.  
Ladder e084 is re-included back into HWDB.  
Please keep an eye on it. 
Please also take all alarms seriously. 
 
<!-- Author: sasha/hugo -->
<!-- Comment: Mon Oct 15 15;40;38 comment by...Oscar -->
I changed the IMON limit for AVDD for SB0W8L4 (e084) to 1080 from 1060 to avoid a pink. Current value is 1075. Since this guy needs monitoring, having it always pink (or ignored) is not going to work very well.


<!-- Date: Mon Oct 15 16:02:41 2007 -->
<h3>Espresso is back!</h3> 
The machine is acting perfectly normal at the moment. While talking to the customer service agent, I was draining the pump (as was done several times on Friday). After draining, the water tank light stopped blinking and the coffee making resumed. I asked her what she did and she said,  
<br> 
"I wiggled my nose left and right three times".  
<br> 
Our Magic Deluxe really lives up to its name. 
However, she believes it is a problem with the filter in the brew group, possibly a stripped screw that was causing misalignment. She is sending a new part. It is not under warranty, but she is sending it for free anyways.<br><br> 
Please be gentle with the machine and cross your fingers when you press the button (or you can wiggle your nose). <br><br> 
We will schedule a Saeco access later this week or next week once the part arrives.
<!-- Author: David -->


<!-- Date: Mon Oct 15 17:07:39 2007 -->
We have been changing the limits in IMON for ignored cells. We have left some cells in the ignored status because they do not look right or becuase the power supply work took place too recently to assure that the currents are stable.<br> 
The ignored cells are currently:<br> 
BIAS SB2W9L4<br> 
BIAS SB3W7L2<br> 
AVDD SB3W7L2<br> 
BIAS SB4W2L4<br> 
AVDD LB1W0L1<br> 
DVDD LB1W0L1<br> 
DVDD LB1W0L2<br> 
AVDD IB0W5L0<br> 
AVDD IB0W5L4<br> 
BIAS IB0W5L3<br> 
<br> 
We will do a second round at the end of this week.  
<!-- Author: Oscar, Roberto, Tino and Pedro -->


<!-- Date: Mon Oct 15 17:08:33 2007 -->
<h3>BLM Check-Out</h3> 
So, before checking out the BLMs, please remember that they work better when the HV cable is plugged in. 
<p> 
I went through ACNET page E4 and followed the nice instructions that we have on our expert pages <a href="https://www-cdfonline.fnal.gov/internal/ops/svxii/svx_for_aces/radmon.html">here</a>  to manually alarm and trip each BLM which aborts the Tevatron. Ricardos diamonds responded as well, and the control room was quite noisy. All 4 BLMs responded well, so all cables are hooked up just fine. 
<p> 
Please note that when we decide to do this, give MCR a call and let them know. Also, you can look at their super top-secret I-67 ACNET page, click on Tevatron, and see if our BLMs were the ones that caused the abort (under B0, CDF SVX Losses). This is the page that MCR looks at.
<!-- Author: Jennifer, Ulrich & Ricardo -->
<!-- Comment: Mon Oct 15 17;27;51 comment by...Ulrich -->
We are also reading back the correct high voltage, after Ricardo fixed the voltage divider in the HV monitoring box that broke shortly before the shutdown.


<!-- Comment: Mon Oct 15 19;58;21 comment by...ronmoore -->
You could just look at the less-secret T67 application.  (You can avoid the "click on Tevatron" step.)
<!-- Comment: Tue Oct 16 05;23;49 comment by...Marcel -->
As usual the Lord of the Tevatron knows it all :-), probably he has gioven names to all his separators. 
<!-- Comment: Tue Oct 16 12;37;12 comment by...ronmoore -->
...separators and Si SPLs... ;-)
<!-- Date: Mon Oct 15 18:26:30 2007 -->
Back by popular demand, <a href="http://www.youtube.com/physics4phun">here</a> is the link for the strongman contest movies; everything with "10/13/07" is from Saturday. Enjoy :-)
<!-- Author: Jennifer :-) -->






<!-- Date: Tue Oct 16 18:08:07 2007 -->
<h4> Cosmics run 251869 </h4> 
When we tried to do a cosmics run we had <i>b0fib05</i> failing config. We had a problem with the initialization of one of the L00 ladders. 
<pre> 
(MLE) b0fib05:Messenger:Oct 16, 2007 03:10:55 PM->Error Initializing HDI Slot 16 Chan 8: L00 B1W3 
</pre> 
We should keep an eye on this ladder.
<!-- Author: Jose -->


<!-- Date: Tue Oct 16 18:18:57 2007 -->
During cosmic run  
<a href="http://www-cdfonline.fnal.gov/java/cdfdb/servlet/RunSummary?RUN_NUMBER=251878" >251878</a> an automatic HRR was issued by svxmon but RC got stuck in the Active to Halt transition. We had to manually override the transition to bring RC to the Start state. 
Inmediately tried to do a coldstart but b0svx00 did not pass partition and was not even pingable. We did a physical reset of the b0svx00 CPU crate, and after checking that FER_messenger was present  we tried again. This time the crate passed partition but hung up during  config. This time we physically reset b0svx00, the crate b0evme17 and all the vrb cards in the crate. The coldstart worked after that and we went back to take cosmics with the full detector on. 
 
 
 
 
 
<!-- Author: Jose/Ricardo -->

<!-- Date: Tue Oct 16 18:46:12 2007 -->
Entered in Silicon database: <ul>
<li>Ladder: LB0W4L1 
<li>problem n: 2149 
<li>Status: fixed
<li>Type: DVDD
<li>Action: Diagnosis_update
<li>entered by: jgarcian 
<li>description is: Limits changed due to a PS swap 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=L00&wedge=B0W4&layer=L1">report</a></ul>
<!-- Author: Problem DB -->
<!-- Comment: Tue Oct 16 18;47;07 comment by...Jose -->
We will have again the automatic PDB entries in the e-log. The server has been updated.


<!-- Comment: Tue Oct 16 23;39;49 comment by...Jose -->
I forgot to mention that the new server is called <i>www-cdfonline.fnal.gov</i>. I have updated the PDB and the IDB. Please tell me if you find any other service not working.
<!-- Date: Tue Oct 16 23:37:32 2007 -->
Important to notice this from the CDF e-log: 
<font color=blue> 
<br> Tue Oct 16 16:22:29. We unmasked the following trigger towers: 
<pre> 
eta 8, phi 9:  
CalCrate:CCAL_03 Admem Slot:17 Admem Trigger Output:3  
CalCrate:WCAL_01 Admem Slot:19 Admem Trigger Output:0  
 
eta 6, phi 18:  
CalCrate:PCAL_04 Admem Slot:20 Admem Trigger Output:0  
CalCrate:WCAL_03 Admem Slot:16 Admem Trigger Output:2  
 
eta 0, phi 4:  
CalCrate:PCAL_01 Admem Slot:17 Admem Trigger Output:6  
</pre> 
 
Three of the four trigger towers now are fine. The (eta=6, phi=18) tower is still triggering at beam crossing due to the WCAL part. We have left this trigger tower masked off. The (eta=8, phi=9) is the trigger tower that had "burst" problems (from the CHA trigger input) in the past, and if it causes problems please page the L1 CAL trigger pager carrier to have it masked off again. 
 
 - Carla, Willis 
</font> 
 
<p>We had some problems with one of these towers and it is back again. We should keep an eye. 
<!-- Author: Jose -->



<!-- Date: Wed Oct 17 03:37:20 2007 -->
Paged at 2:40 with the silicon on standby because the losses were spikey. See details  
<a href= 
'http://www-cdfonline.fnal.gov/cgi/elog/elog.pl?nb=2007&action=view&page=802&frame=2&anchor=02:17:08.337'> 
here</a>. 
 
 
  
<!-- Author: Ricardo -->


<!-- Date: Wed Oct 17 13:28:49 2007 -->
<b>Controlled access for ISL RTD investigation</b> 
<p>Investigated the oscillatory behavior of RTDs ISL_TE_CCW3L7_1IN and ISL_TE_CCW3L7_1OUT. Inspected ribbon cable connectors at detector DIN rail. They looked fine. Pushed on them to seat them better; they did not move. RTDs still oscillating. Swapped wires for ISL_TE_CCW3L7_1OUT and ISL_TE_CCW3L7_2IN. Oscillations followed sensor. Undid the swap.</p> 
 
<p> Conclusion: the problem is upstream of the detector DIN rail, possibly at the ribbon cable interconnect in the west bore. There has also been some speculation that we are picking up the COT SL7 preamp oscillations.</p> 
 
<p>Technical note: when doing the swap, we turned the ISL off and  forced the values of ISL_TE_CCW3L7_1IN, 1OUT, and 2IN to ~10 deg C (in order to not fire ubertrip or dew point trips) and forced the the alarm word corresponding to their RTD module (WX3049) to 0 in order to not fire any temperature trips.  In principle we should have just forced the three bits of this word corresponding to the RTDs in question to 0, but I couldn't remember how to do that and we just forced the whole word to 0.  Anyway doing this allowed us to avoid any trips during the swap. 
</p>
<!-- Author: Andy H., Ricardo E., Tom J. -->
<!-- Comment: Wed Oct 17 23;37;21 comment by...Ulrich -->
You can bring up the data window and display the numbers in binary, then you can flip single bits.
<!-- Date: Wed Oct 17 13:54:54 2007 -->
<pre>We put a scope on the RTD readback lines for the ISL West L7 B3 line input and output, using the DIN rails in the cabinet on the first floor.  We saw the ~26 mV average voltage on both the excitation lines and the readback lines.  We were looking for electrical pickup, and indeed found quite a lot.  The signals oscillate with a period of ~5 microseconds, with an amplitude of 3 mV or so.  Even RTDs without the readback oscillations show the same behavior. 
 
We surmise that the RTD readback is averaging over a longer timescale, and that the oscillations in our temperature readback are masked by the larger and faster pickup noise when trying to look at it with an oscilloscope.  It's hard to extract information from this.</pre>
<!-- Author: Tom and Ricardo -->


<!-- Date: Wed Oct 17 14:16:16 2007 -->
<center><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-11896&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-11897' ></a><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-11898&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-11899' ></a></center>
<!-- Author: sasha -->
<!-- Comment: Wed Oct 17 14;27;46 comment by...sasha/hugo/miguel -->
<pre>Unfortunately, e084 went back into its old failure mode: no DVDD current. One can also see that it looks like drop in DVDD happened at the same time as increase in AVDD. It seems that AVDD is increased by exactly the amount of DVDD current. It reminds the jumper failure mode except for two issues: jumper failure results in a permanent loss of z-side; because it's a wire bond failure, there are no magic "come back's". </pre>


<!-- Date: Wed Oct 17 14:31:06 2007 -->
<center><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-11900&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-11901' ></a><a href='/elog/notebooks/silicon/Wed_Oct_17_2007_143051.ps'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-11903' ></a></center>
<!-- Author: sasha -->
<!-- Comment: Wed Oct 17 14;35;19 comment by...sasha/hugo/miguel -->
<pre>e184 was exclude from HWDB because of a history of drooping bias. We re-included it back. Bias seems to be OK. We should keep this ladder powered for some time to make sure BIAS is stable. The other problem with this ladder is that it has CAP_ID problem on chip-5 in NN mode, but not in RA. Looking at svxdaq plots, one can see that chip5 is almost dead anyway. So, we can solve the problem of CAP_ID by putting this chip in RA mode with threshold set to 255.  </pre>

<!-- Date: Wed Oct 17 16:16:06 2007 -->
Entered in Silicon database: <ul>
<li>Ladder: IB0W0L2 
<li>problem n: 1622 
<li>Status: unfixable
<li>Type: Unknown
<li>Action: Removed_hdwdb
<li>entered by: sasha 
<li>description is: We re-included and tested this ladder again. It still returns no data. Given the previous history of this ladder, I declare it unfixable. 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=ISL&wedge=B0W0&layer=L2">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Wed Oct 17 18:00:04 2007 -->
Entered in Silicon database: <ul>
<li>Ladder: SB0W8L4 
<li>problem n: 1287 
<li>Status: unfixable
<li>Type: DVDD
<li>Action: Removed_hdwdb
<li>entered by: sasha 
<li>description is: Unfortunately, this ladder has the same problem of zero DVDD current after a short recovery period (see <a href= 'http://www-cdfonline.fnal.gov/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=375&frame=2&anchor=14:16:16'> e-log</a>). I changed it to unfixable and excluded from HWDB. 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B0W8&layer=L4">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Wed Oct 17 18:06:50 2007 -->
Entered in Silicon database: <ul>
<li>Ladder: SB1W8L4 
<li>problem n: 2139 
<li>Status: needs_work
<li>Type: Unknown
<li>Action: Diagnosis_update
<li>entered by: sasha 
<li>description is: We re-included this ladder and tested it in SVXDAQ. It was biased for ~5h and current was stable. It also gives data. A problem with CAP_ID on chip89 can be fixed by putting it to RA mode and setting threshold to 255 (see <a href= 'http://www-cdfonline.fnal.gov/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=375&frame=2&anchor=14:31:06'> e-log</a>). We need to keep biased this ladder whenever it's possible to see if it holds bias before we can finally included it for data taking.  
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B1W8&layer=L4">report</a></ul>
<!-- Author: Problem DB -->



<!-- Date: Wed Oct 17 19:30:09 2007 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-11904&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-11905  width='300' align='top'></a></td><td>Here's the Bias current of f100 to be compared with the fluctuation of the temperature on the line CCW3L7_1OUT that will be pasted later. The bias current is very stable while the  temperature fluctuates about 1 degree C.</td></tr></table>
<!-- Author: Tom & Ricardo -->
<!-- Comment: Wed Oct 17 19;35;36 comment by...Tom&Ricardo -->
Forgot to mention that during this test IMON was changed to be able to plot the current every 5 seconds. In this configuration IMON currents were sampled, as opposed to averaged. IMON is now back to its default settings. 
<!-- Date: Wed Oct 17 19:33:26 2007 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-11906&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-11906  width='300' align='top'></a></td><td>Temperature seen on CCW3L7 inputs and outputs during the 
test to see how correlated the temperatures and bias currents are.</td></tr></table>
<!-- Author: Tom Junk -->



<!-- Date: Wed Oct 17 19:47:33 2007 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-11907&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-11907  width='300' align='top'></a></td><td>Mysteriosly enough, the readback temperature of the input went ever so slightly down during this test, while the temperature of the output line went up.  They recovered to their pre-test values when the ladder was powered off.</td></tr></table>
<!-- Author: Ricardo & Tom -->


<!-- Date: Wed Oct 17 20:05:56 2007 -->
We hockerized PS crate 6 to see if that fixes the DOIM2V and DOIM5V pinkies of the e09 wedge. It didn't work, and we are going to set the ladder to "ignore" in IMON so it does not bother the SciCo during the night. 
 
<!-- Author: Tom & Ricardo -->



<!-- Date: Thu Oct 18 07:27:53 2007 -->
I was paged at 4am because they had problems with an AVDD pinky and to do the COLDTART run indicated by the flow-chart on pinkies. I have looked with the Ace and we could not find the detailed instructions on how to take a COLDSTART Run.<br> 
In fact, most of the documentation for the aces is a bit unfriendly and hard to handle. Should we revisit it?
<!-- Author: Oscar -->


<!-- Date: Thu Oct 18 07:29:10 2007 -->
Since they had problems running and with fib05, I have done a COLDSTART run myself and run doe 3400 events. No problems. I will take a look on the pinkies now.
<!-- Author: Oscar -->

<!-- Date: Thu Oct 18 07:45:28 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: oscar 
<li>description is: The current has drop again this night, producing a pinky. It is stable now around 1010. Considering the history of this current and the changes from time to time, I will put it to ignore but monitor the changes. 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B5W5&layer=L4">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Thu Oct 18 07:53:18 2007 -->
Entered in Silicon database: <ul>
<li>Ladder: SB5W8L2 
<li>problem n: 2156 
<li>Status: fixed
<li>Type: AVDD
<li>Action: IMON_limits
<li>entered by: oscar 
<li>description is: Changing the IMON limits. After the 2007 shutdown work, the current has been stable very close to the high end, giving a pinky cell in IMON from time to time.<table border=1>
<tr><th>IMON LIMITS</th><th>Old</th><th>New</th></tr>
<tr><td><b>Nominal</b></td><td>826</td><td>835</td></tr>
<tr><td><b>Lower</b></td><td>790</td><td>800</td></tr>
<tr><td><b>Upper</b></td><td>835</td><td>845</td></tr></table> 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B5W8&layer=L2">report</a></ul>
<!-- Author: Problem DB -->



<!-- Date: Thu Oct 18 07:56:45 2007 -->
I have taken a look on the VDOIM currents we have ignored in IMON (SB0W6 and SB0W9) and the values seem to have changed a lot since Monday. I keep them ignored. We should retune the IMON limits as soon as we have steady data-taking.
<!-- Author: Oscar -->


<!-- Date: Thu Oct 18 14:50:35 2007 -->
While I was over getting some coffee, Sasha mentioned that the PDB was not showing the latest HWDB status for ladders that were recently changed.  After a little investigation Jose and I found that the cron jobs for svxii on b0gateway are no longer running.  Badgett confirms that the crontab file was probably blown away with the upgrade to SL4 a couple of days ago.  If anyone has a copy of the crontab file floating around, let Jose know.
<!-- Author: Jose, Sasha, Mark -->
<!-- Comment: Thu Oct 18 15;02;05 comment by...Mark -->
I just realized that the cron jobs are documented at:

http://b0sili01.fnal.gov/cgi-bin/TWiki/bin/view/Silicon/SiliconScripts

So the crontab can be rewritten if there is not a backup floating around.

<!-- Comment: Thu Oct 18 15;52;23 comment by...Jose -->
I have checked b0gateway. They made a yum update the 16th, one of the packages updated is:
<pre>
Oct 16 09:36:13 Updated: vixie-cron.i386 4:4.1-47.EL4
</pre>
<!-- Comment: Thu Oct 18 18;01;20 comment by...Jose -->
Badget said that they have a backup...
<!-- Date: Thu Oct 18 15:40:53 2007 -->
Entered in Silicon database: <ul>
<li>Ladder: SB2W11L2 
<li>problem n: 1993 
<li>Status: needs_observation
<li>Type: TX
<li>Action: Diagnosis_update
<li>entered by: sasha 
<li>description is: Problem disappeared on 07/21/07. No errors in NN and RA modes in SVXDAQ. Need to keep an eye on it. 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B2W11&layer=L2">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Thu Oct 18 15:43:55 2007 -->
Entered in Silicon database: <ul>
<li>Ladder: SB0W10L4 
<li>problem n: 2064 
<li>Status: needs_access
<li>Type: Chip_bit_error
<li>Action: Diagnosis_update
<li>entered by: sasha 
<li>description is: Bit5 high confirmed. Need a fiber swap. 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B0W10&layer=L4">report</a></ul>
<!-- Author: Problem DB -->




<!-- Date: Thu Oct 18 17:44:56 2007 -->
<center><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-11908&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-11908' width='300'></a><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-11909&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-11910' ></a><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-11911&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-11912' ></a></center>
<!-- Author: Tom and Jose -->
<!-- Comment: Thu Oct 18 17;52;12 comment by...Tom and Jose -->
They have tried the new sophisticated flow meter... and it works!!! We now know the flow through the DI circuit (note that DPT is 2 psi). Thus we are flowing 23 GPH which is... around... uuuhmm... 1.45 lpm.
<br> Now that we know the flow in the pipe we can search for a nicer flow meter.

<!-- Comment: Thu Oct 18 17;55;11 comment by...Jose -->
From the Cryo e-log:
<pre>
Thu Oct 18 15:24:41 Dean modified the ISL piping between the deionizer and the filter by removing both the sight glass and the flow switch and installed a flow meter click here for drawing. With the position of MV-2013-W where it was, we had a flow of 27 GPH (1.7 LPM). We then slowly opened MV-2013-W fully and the ball did not move at all meaning flow was <8 GPH (<.5 LPM). We then slowly throttled MV-2013-W until we read 10 GPH (.63LPM)which gave us 1.5 PSID across the filter system. We then slowly throttled MV-2013-W more until we read 20 GPH (1.26 LPM)which gave us 2.0 PSID across the filter system. This is where we stopped. We will watch performance and look for a similar device that will give us a readout to the controls system so we can see it in iFIX. - Bill Noe
</pre>


<!-- Date: Thu Oct 18 18:50:58 2007 -->
Entered in Silicon database: <ul>
<li>Ladder: SB3W2L0 
<li>problem n: 868 
<li>Status: needs_work
<li>Type: Chip_capid
<li>Action: Diagnosis_update
<li>entered by: sasha 
<li>description is: Bit5 low affecting mostly channel_ID is confirmed. Not sure if it affects CAP_ID (hard to catch with only two chips). Drops readout from chip82. This ladder has BE kludge, can we do a fiber swap for it? 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B3W2&layer=L0">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Thu Oct 18 18:59:15 2007 -->
Entered in Silicon database: <ul>
<li>Ladder: SB0W0L2 
<li>problem n: 1490 
<li>Status: needs_work
<li>Type: Chip_bit_error
<li>Action: Diagnosis_update
<li>entered by: sasha 
<li>description is: Tested this ladder in SVXDAQ again. Error rate is low (~20/3K) if all ISEL bits for chip89 are set to zero. Checked HWDB to make sure it has the same settings. It looks like chip89 returns almost no useful data anyway, so if problem strikes with higher rate we can sparse this chip out (threshold to 255).    
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B0W0&layer=L2">report</a></ul>
<!-- Author: Problem DB -->



<!-- Date: Thu Oct 18 19:41:59 2007 -->
I was paged because they plan to inject protons... which is great. However, the SciCo told me something about a channel that Sasha left to On and that the group (?) promised to turn it off before leaving. It seems that it was on Stand-by, but in any case I was not aware of anything like that: nobody informed of such plan and there is no entry in the e-log reporting this<br> 
I talked directly with Miguel when they finished their work on the PDB review and he did not mention anything... I would say we should improve the communication since I had no idea of what to do (except playing safe putting silicon to Stand-by).<br> 
The Shiftcrew confirm that iFix shows the silicon on Stand-by, so I guess this is what we want.
<!-- Author: Oscar. -->
<!-- Comment: Thu Oct 18 22;09;35 comment by...Jose -->
They paged me at the same time they paged you. I think he was talking with you when I called and I could not speak with him. 
I was leaving Fermi when I got the page but I had switched the ladder to standby before leaving. 
<br> Silly me that thought that the SciCo would realize that everything was in Standby.

<!-- Comment: Fri Oct 19 09;53;26 comment by...sasha. -->
<pre>My bad. Even though I told Jose about this ladder, I still should have left an entry in e-log.</pre>


<!-- Date: Fri Oct 19 16:21:18 2007 -->
iFix PC was rebooted this afternoon. The workspace didn't come up right away, but did after about 10 minutes. iFix was running the whole time, it was just the workspace window that wouldn't display. Weird.
<!-- Author: Jennifer :-) & Tom -->


<!-- Date: Fri Oct 19 18:03:21 2007 -->
<h3> Kicker pre-fire </h3> 
 
Let me copy directly what Steve wrote... 
<pre> 
At 0948 this morning, TeV abort kicker PAK3 had a prefire due to a power supply problem. After much discussion of different options with Salah Chaurize, the AD Run Coordinator, we have decided to require 8 hours of conditioning without beam before PAK3 is returned to running at 980 GeV; the MCR shift crew can do 150 GeV studies before this time. Right now, it appears they are debating which of these two options to select. More when we know more. 
 
Meanwhile, Willis and Alexi are checking that plug source running works correctly. 
 
One upsetting facet of this affair is that there was a kicker pre-fire and we were not called. I will remind the MCR shift crew that they should call us any time there is a kicker pre-fire with beam in the Tevatron. 
</pre>
<!-- Author: Oscar/Ricardo/Jose -->
<!-- Comment: Fri Oct 19 18;17;36 comment by...Jose -->
This is what the MCR said:
<pre>
09:48:37-   One uncoalesced bunch C:PAK3 pre-fire killed the beam. Contacting experts.  - Thorson
-- Fri Oct 19 09:52:09 comment by...m.m --  Tev was at flattop. No ill effects. placing in dry squeeze.
-- Fri Oct 19 09:57:00 comment by...Thorson --  George Krafczyk is looking into the problem. He'll get back to us.
-- Fri Oct 19 13:27:01 comment by...DJC --  PAK3 appears to have a PS problem. Estimate is 4 hours for repair completion.
</pre>
The weird thing is that no abort was recorded in the java application. Nothing was noticed on IMON at all. It does not seem clear what exactly happened.
<br> The bottom line is that they have to replace the kicker and condition it. They already fixed it and will do the conditioning (8 hours) tonight without beam.
<br> The conclusion of the meeting is summarized in the Run Coordinator <a href=http://www-bd.fnal.gov/cgi-mach/machlog.pl?nb=runco&action=xe&page=1007&time=17:18:57> e-log </a>.
<!-- Date: Fri Oct 19 18:08:54 2007 -->
We just made a COLDSTART to check everything was fire after the kicker pre-fire we were not informed about. Everything was fine and only fib05 failed cofig with<br> 
<br> 
Error Initializing HDI Slot 16 Chan 8: L00 B1W3 
<br><br> 
that was there before... this channel would require some masking.
<!-- Author: Oscar/Jose -->



<!-- Date: Sat Oct 20 00:05:48 2007 -->
fib05 is giving troubles because of the problematic channel LB1W3 HDI 16 channel 8, since it fails Config and the aces are getting confused. I instructed them to page me if they need to do a Coldstart or so.<br> 
In the morning I will take a fast look on the channel and mask it if needed.
<!-- Author: Oscar. -->


<!-- Date: Sat Oct 20 10:14:57 2007 -->
I have masked channel fa33 to avoid the error in the Config state for FIB05. I was lucky this was explained in the Silicon Twiki since I never did it before.<br> 
HOWEVER, I tried to run SVXDAQ to check if the ladder was returning data and I was not able to run. I could not find any clear instructions on the Twiki about how to setup, and when I tried to run it got stuck (I remember this happened to me once, but I do not remember the reason or how to fix it). In addition, several pinkies appear in the channels I was trying to use, so I decided to forget about the SVXDAQ, do a standard COLDTART and mask the ladder.<br> 
I recommend someone with more expertise with the SVXDAQ than me take a look on this ladder and suggest to make a twiki page as "SVXDAQ for low-level checking" (or make a better pointing to it from the procedures page). You can call it "SVXDAQ for the stupid silicon expert"... I do not mind, I just want to be able to run that once per semester, that is my current average. As you might guess, that time is when I need it to run is the time we need to run it for sure. 
 
  
<!-- Author: Oscar -->
<!-- Comment: Sat Oct 20 10;17;03 comment by...Oscar -->
<pre>In case someone wants to check, this is what I got when doing "set defaults" on SVXDAQ:

Initing DDR: 3 Fib Pipe: 8 in   Crate 5, Slot 16  fa33   -----> Error <-----
 TRIED TO WRITE:
 0 80 0 80 0 80 0 80 0 80 0 80 0 80 0 80 15 1d 52 80 a 28 6c f8 1b 0 10 0 10 0 10 0 10 0 10 0 10 0 10 0 b0 a2 43 1a 10 1 85 d ff 2 0 2 0 2 0 2 0 2 0 2 0 2 0 2 0 56 74 48 5 22 a0 b0 e1 6f
 READBACK:
 0 80 ff ff ff ff ff cf ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 7f ff ff ff ff fb ff ff ff fb ff ff ff ff ff ff ff ff ff ff ff ff ff 3f f8 ff ff ff fd ff ff ff 7f ff ff ff ff 7f
</pre>

<!-- Comment: Sat Oct 20 10;38;49 comment by...Oscar -->
Well, I found some instructions on the Twiki, but they are under the paragraph "Pages to be written", so it is not a surprise I could not find it.<br>
I followed the instructions and I got the same results: the run ran for a few events (6,12 or so) and got stuck. Even with those events, I got a lot of errors from the ladder I was checking:
<br>
<pre>
R 1706 E 4 Error: OO Sequence      Fib 0 Pipe 8 Chip 0: .. 15, 8 ..
R 1706 E 4 Error: OO Sequence      Fib 0 Pipe 8 Chip 0: .. 31, 24 ..
R 1706 E 4 Error: OO Sequence      Fib 0 Pipe 8 Chip 0: .. 47, 40 ..
R 1706 E 4 Error: OO Sequence      Fib 0 Pipe 8 Chip 0: .. 63, 56 ..
R 1706 E 4 Error: OO Sequence      Fib 0 Pipe 8 Chip 0: .. 79, 72 ..
R 1706 E 4 Error: OO Sequence      Fib 0 Pipe 8 Chip 0: .. 95, 88 ..
</pre>
<br>
As indicated above, someone would have to check this ladder anyway.

<!-- Comment: Sat Oct 20 11;23;40 comment by...Marcel -->
Dear Oscar<br>
the write and readback are the bitstream you are downloading to the chip, it is an easy way to cross-check, that what you are writing is coming back the same way. Anyway, clearly, there is something wrong here,which looks like a few bits high (0-2) although the pattern is quite interesting. I'd do a fiber swap as soon as i have the opportunity and also have a look at the raw data to get a clearer idea why. <br>
have a look at the raw data as well. Btw, if I recall right the init readback is happening on bit 2 or 3, (that is written down somewhere in Ankushs SVX3 talk), so this would fit well the symptoms. <br>
Anyway, this certainly an interesting case and not easy to diagnose ... 



<!-- Comment: Sat Oct 20 11;54;55 comment by...Ankush -->
<em>while listening to the Radiohead review on NPR</em>

<pre>
I agree with Marcel that is a bit 3 error: Bit 3 is also used to return the initialisation bit stream from the chips. It also consistent with the error you're seeing.

So here's a quick tutorial on how to diagnose this.

15,8  --> the correct sequence could be 15,16 or 7,8.

So convert this to binary:

15 --> 0x01111
8  --> 0x01000

7  --> 0x00111

16 --> 0x10000

Let's test the two hypothesis:

1) Assume the sequence should be 15,16.  How does 8 differ from 16?  Well this can only occur if bit 3 is shifted to bit 4.

2) Assume the sequence should be 7,8. How does 7 differ from 15 ?
Well the only difference is 15 has bit 3 high.

Can 1) be true? Well if it were true, a lot of odd things would be going on since bit shifting in this way is pretty severe.  So probably unlikely.
2) seems more likely...bit 3 stuck high.  If you repeat this exercise for remaining errors, you&#39;ll see this is true.  Also the fact that the ladder fails initialisation is consistent with an error on bit 3.  

Also if you look at the graphs form SVXDAQ, you should see repeated blocks of read out channels.

Next step:  My usual trick is to increase the RDriver value from the default of 4.  That may solve this read back.  There may some new tricks.....it&#39;s been a while since I did this for real.

</pre>

<!-- Date: Sun Oct 21 15:52:58 2007 -->
Entered in Silicon database: <ul>
<li>Ladder: IB0W3L3 
<li>problem n: 2157 
<li>Status: fixed
<li>Type: DVDD
<li>Action: IMON_limits
<li>entered by: oscar 
<li>description is: Although value does not seem completely stable, I have changed the IMON limits to avoid having it ignored the whole time... Limits are a bit tighter to keep some monitoring.<table border=1>
<tr><th>IMON LIMITS</th><th>Old</th><th>New</th></tr>
<tr><td><b>Nominal</b></td><td>358</td><td>325</td></tr>
<tr><td><b>Lower</b></td><td>335</td><td>315</td></tr>
<tr><td><b>Upper</b></td><td>435</td><td>335</td></tr></table> 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=ISL&wedge=B0W3&layer=L3">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Sun Oct 21 15:56:52 2007 -->
Entered in Silicon database: <ul>
<li>Ladder: IB0W5L0 
<li>problem n: 2158 
<li>Status: fixed
<li>Type: AVDD
<li>Action: IMON_limits
<li>entered by: oscar 
<li>description is: Changing limits after the 2007 shutdown work. Current seems to be stable and with a smaller spread than before.<table border=1>
<tr><th>IMON LIMITS</th><th>Old</th><th>New</th></tr>
<tr><td><b>Nominal</b></td><td>1107</td><td>1145</td></tr>
<tr><td><b>Lower</b></td><td>1070</td><td>1125</td></tr>
<tr><td><b>Upper</b></td><td>1110</td><td>1165</td></tr></table> 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=ISL&wedge=B0W5&layer=L0">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Sun Oct 21 16:00:21 2007 -->
Entered in Silicon database: <ul>
<li>Ladder: IB0W5L3 
<li>problem n: 2159 
<li>Status: fixed
<li>Type: AVDD
<li>Action: IMON_limits
<li>entered by: oscar 
<li>description is: This ladder has a current close to the high-end limit. It is yellow, but a small change will make it pink. Current seems to be stable sfter the shutdown, so I chancge the limits.<table border=1>
<tr><th>IMON LIMITS</th><th>Old</th><th>New</th></tr>
<tr><td><b>Nominal</b></td><td>1073</td><td>1080</td></tr>
<tr><td><b>Lower</b></td><td>1035</td><td>1050</td></tr>
<tr><td><b>Upper</b></td><td>1080</td><td>1100</td></tr></table> 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=ISL&wedge=B0W5&layer=L3">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Sun Oct 21 16:03:06 2007 -->
Entered in Silicon database: <ul>
<li>Ladder: IB0W5L4 
<li>problem n: 2160 
<li>Status: fixed
<li>Type: AVDD
<li>Action: IMON_limits
<li>entered by: oscar 
<li>description is: Changing limits after the 2007 shutdown work. Current is stable after the PS change.<table border=1>
<tr><th>IMON LIMITS</th><th>Old</th><th>New</th></tr>
<tr><td><b>Nominal</b></td><td>1098</td><td>1130</td></tr>
<tr><td><b>Lower</b></td><td>1055</td><td>1110</td></tr>
<tr><td><b>Upper</b></td><td>1100</td><td>1150</td></tr></table> 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=ISL&wedge=B0W5&layer=L4">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Sun Oct 21 16:09:19 2007 -->
Entered in Silicon database: <ul>
<li>Ladder: LB1W0L0 
<li>problem n: 2012 
<li>Status: fixed
<li>Type: AVDD
<li>Action: IMON_limits
<li>entered by: oscar 
<li>description is: Changing limits for IMON after the PS exchange. It should be noted that the cell is yellow in IMON, but the value has clearly changed and it is stable around the previous upper limit.<table border=1>
<tr><th>IMON LIMITS</th><th>Old</th><th>New</th></tr>
<tr><td><b>Nominal</b></td><td>165</td><td>175</td></tr>
<tr><td><b>Lower</b></td><td>160</td><td>170</td></tr>
<tr><td><b>Upper</b></td><td>175</td><td>185</td></tr></table> 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=L00&wedge=B1W0&layer=L0">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Sun Oct 21 16:11:23 2007 -->
Entered in Silicon database: <ul>
<li>Ladder: LB1W0L1 
<li>problem n: 1994 
<li>Status: fixed
<li>Type: AVDD
<li>Action: IMON_limits
<li>entered by: oscar 
<li>description is: Change in the IMON limits due to the 2007 shutdown work (excehange of the power supply).<table border=1>
<tr><th>IMON LIMITS</th><th>Old</th><th>New</th></tr>
<tr><td><b>Nominal</b></td><td>165</td><td>155</td></tr>
<tr><td><b>Lower</b></td><td>162</td><td>150</td></tr>
<tr><td><b>Upper</b></td><td>168</td><td>160</td></tr></table> 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=L00&wedge=B1W0&layer=L1">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Sun Oct 21 16:13:27 2007 -->
Entered in Silicon database: <ul>
<li>Ladder: LB1W0L3 
<li>problem n: 1995 
<li>Status: fixed
<li>Type: AVDD
<li>Action: IMON_limits
<li>entered by: oscar 
<li>description is: Change in the IMON limits after the change in the PS during the 2007 shutdown.<table border=1>
<tr><th>IMON LIMITS</th><th>Old</th><th>New</th></tr>
<tr><td><b>Nominal</b></td><td>240</td><td>245</td></tr>
<tr><td><b>Lower</b></td><td>238</td><td>240</td></tr>
<tr><td><b>Upper</b></td><td>243</td><td>250</td></tr></table> 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=L00&wedge=B1W0&layer=L3">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Sun Oct 21 16:15:31 2007 -->
Entered in Silicon database: <ul>
<li>Ladder: LB1W0L1 
<li>problem n: 2161 
<li>Status: fixed
<li>Type: DVDD
<li>Action: IMON_limits
<li>entered by: oscar 
<li>description is: Big change in the nominal current that is stable after the PS exchange in the 2007 shutdown.<table border=1>
<tr><th>IMON LIMITS</th><th>Old</th><th>New</th></tr>
<tr><td><b>Nominal</b></td><td>62</td><td>33</td></tr>
<tr><td><b>Lower</b></td><td>60</td><td>28</td></tr>
<tr><td><b>Upper</b></td><td>75</td><td>38</td></tr></table> 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=L00&wedge=B1W0&layer=L1">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Sun Oct 21 16:17:36 2007 -->
Entered in Silicon database: <ul>
<li>Ladder: LB1W0L2 
<li>problem n: 2162 
<li>Status: fixed
<li>Type: DVDD
<li>Action: IMON_limits
<li>entered by: oscar 
<li>description is: Change in the IMON limits after the PS exchange during the 2007 shutdown work.<table border=1>
<tr><th>IMON LIMITS</th><th>Old</th><th>New</th></tr>
<tr><td><b>Nominal</b></td><td>62</td><td>48</td></tr>
<tr><td><b>Lower</b></td><td>55</td><td>43</td></tr>
<tr><td><b>Upper</b></td><td>75</td><td>60</td></tr></table> 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=L00&wedge=B1W0&layer=L2">report</a></ul>
<!-- Author: Problem DB -->



<!-- Date: Sun Oct 21 16:22:21 2007 -->
I have changed the IMON limits for several cells that were ignored or yellow and related to the last PS changes. I have checked with the Current plotter that they were stable enough to hope they will stay like that for a while.<br> 
Currently only 5 cells in SVX remain ignored. 4 DOIMs (that we changed at the beginning of the week) and the AVDD for SB5W5L4 that is under observation.<br> 
Of course, the "pinky game" has not finished yet since lots of BIAS pinkies are waiting there to show up as soon as the detector is biased.
<!-- Author: Oscar -->


<!-- Date: Sun Oct 21 23:51:09 2007 -->
We took two d-mode calibration runs today taking advantage of a Tevatron Quench. The are with no-beam and DPSON (252259) and DPSOFF (252260). When making the request for the analysis of the data, the job failed. Experts will be contacted.
<!-- Author: Jose and Oscar -->

<!-- Date: Mon Oct 22 08:56:06 2007 -->
Entered in Silicon database: <ul>
<li>Ladder: LB1W3L3 
<li>problem n: 2163 
<li>Status: needs_work
<li>Type: No_Init
<li>Action: Diagnosis
<li>entered by: oscar 
<li>description is: I have masked the INIT readback for this ladder to avoid FIB05 to fail config transition. It seems to be related to a bit problem, so further work is required. 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=L00&wedge=B1W3&layer=L3">report</a></ul>
<!-- Author: Problem DB -->



<!-- Date: Mon Oct 22 09:00:36 2007 -->
<h2>Summary of the week</h2> 
 
Quiet week with very few minor problems. The main issues and work were the following: 
 
<ul> 
   <li>Some PS work on Monday (LB1W0 repaired). You can see the details 
   <a href='http://www-cdfonline.fnal.gov/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=375&frame=2&anchor=14:08:55'>here</a>. 
   </li> 
   <li> BLM check-out on Monday. See details 
   <a href='http://www-cdfonline.fnal.gov/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=375&frame=2&anchor=17:08:33'>here</a>. 
   </li> 
   <li> Access for ISL RTD investigation on Wednesday. See details 
   <a href='http://www-cdfonline.fnal.gov/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=375&frame=2&anchor=13:28:49'>here</a>. 
   </li> 
   <li>New flow meter installed to know the low through the DI circuit. 
   </li> 
 
   <li> An abort kicker pre-fire happened on Friday afternoon. After some discussion 
        about the plan, they took some time to fix it and resume beam studies. No 
        effect of the prefire was observed (silicon was at Stand-by and current 
        was low at the Tevatron. 
   </li> 
 
   <li> FIB05 was failing config because of the init readback from fa33. We masked 
        the init readback, but it seems to be a bit-problem. It needs some 
        investigation. 
   </li> 
   <li> Several Cosmics runs taken during the week for general testing. Also, 
        we took D-Mode calibrations on Sunday Evening. 
   </li> 
   <li> Lots of PDB reviews during the week. 
   </li> 
   <li> Several changes in the IMON limits to avoid pinkies. BIAS cells 
        are not yet included in the changes. 
   </li> 
</ul>  
<!-- Author: Oscar -->