<!-- Title: 10:49:04  Mon Oct 16 2006 -->
<!-- Crewchief: Ignacio (MPC) -->
<!-- Op1: Ankush(SPL) -->
<!-- Op2: &nbsp; -->
<!-- Op3: &nbsp; -->
<!-- Op4: &nbsp; -->
<!-- Op5: &nbsp; -->
<!-- Op6: &nbsp; -->
<!-- Notes: -->
Beam is expected late in week. 
 Meanwhile continue: 
        <li>quite time studies,</li> 
        <li>ISL threshold studies+cosmics and</li> 
        <li>labeling activities.</li>


<!-- Date: Mon Oct 16 11:33:07 2006 -->
<table border=0><td><tr><td bgcolor=#e0e030><h3>Please return your keys by 16:00! Today!</h3></td></tr></td></table>
<!-- Author: Jennifer :-) -->


<!-- Date: Mon Oct 16 11:35:30 2006 -->
Ulrich and Jennifer are back from re-installing the BLMs. There are a whole bunch of cables up there... no problems were encountered. 
<p> 
As a note to self, and to other BLMers, make sure that when you disassemble the bolts, reassemble them when placing them in the toolbox. Makes life easier.
<!-- Author: Jennifer :-) & Ulrich -->


<!-- Date: Mon Oct 16 11:51:15 2006 -->
<pre>The Diamonds and the new BLM's are powered up.  
We will monitor them for one hour to do studies without the solenoid on.  After an hour the solenoid can start ramping up. 
So, PLEASE DO NOT TURN THE SOLENOID ON BEFORE 1 PM. 
</pre>
<!-- Author: Ricardo  -->
<!-- Comment: Mon Oct 16 11;51;41 comment by...Ricardo  -->
<pre>Sorry, wrong elog
</pre>


<!-- Date: Mon Oct 16 12:00:54 2006 -->
<h3>Cooling Down the Silicon</h3> 
We just started to bring the Silicon back to regular operating temperatures after the plug pull. The plan is 
<ul> 
<li>SVX: 0°C → -3°C → -6°C (turn on detector) → -10°C</li> 
<li>ISL: 15°C → 10°C → 6°C (turn on detector)</li> 
</ul> 
The first step has been done around 11:45.
<!-- Author: Ulrich -->
<!-- Comment: Mon Oct 16 12;57;08 comment by...Ulrich -->
Ankush has started to power up the Silicon. As a last step, I bring SVX to -10°C. Also the PLC trip limits are back to where they were: all of L00 at 2°C (from 4°C), ISL CPC at 15°C (from 18°C), SVX BH at 2°C (from 6°C).
<!-- Date: Mon Oct 16 12:45:14 2006 -->
<table border=0><td><tr><td bgcolor=#e0e030><h3>CAEN 5V Enables are now ON</h3> 
 
</td></tr></td></table>
<!-- Author: Ankush -->



<!-- Date: Mon Oct 16 13:20:11 2006 -->
<h3>PS-GUI kaka</h3> 
 
<pre> 
[svxii@b0dasvx01 PSfiles]$ Status change prohibited 
ch = 0 
pcStatus = 1 
status = 2 
channelStatus = -1 
java.lang.ExceptionInInitializerError 
        at gov.fnal.robin.rRequest.unmarshal_response(rRequest.java:568) 
        at gov.fnal.robin.rRequest.get_response(rRequest.java:387) 
        at gov.fnal.robin.rRequest.invoke(rRequest.java:177) 
        at CAEN.CaenVme.CaenClient.getSiliconInfo(CaenClient.java:582) 
        at CAEN.PWR.resetValuesFromVMEFunction(PWR.java:530) 
        at CAEN.PWR.access$000(PWR.java:43) 
        at CAEN.PWR$resetValuesFromVMEThread.run(PWR.java:429) 
        at CAEN.PWR.resetValuesFromVME(PWR.java:475) 
        at CAEN.PSControlForm.refresh(PSControlForm.java:1627) 
        at CAEN.PSControlForm.access$000(PSControlForm.java:41) 
        at CAEN.PSControlForm$1.actionPerformed(PSControlForm.java:752) 
        at javax.swing.Timer.fireActionPerformed(Timer.java:271) 
        at javax.swing.Timer$DoPostEvent.run(Timer.java:201) 
        at java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:189) 
        at java.awt.EventQueue.dispatchEvent(EventQueue.java:478) 
        at java.awt.EventDispatchThread.pumpOneEventForHierarchy(EventDispatchThread.java:201) 
        at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:151) 
        at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:145) 
        at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:137) 
        at java.awt.EventDispatchThread.run(EventDispatchThread.java:100) 
Caused by: java.lang.NullPointerException 
        at org.omg.CORBA.CompletionStatus.<init>(CompletionStatus.java:23) 
        at org.omg.CORBA.CompletionStatus.<clinit>(CompletionStatus.java:6) 
        ... 20 more 
 
[2]    Done                          java -Xbootclasspath/p:/cdf/onln/code/cdfprod/robin/v2_4_10/classes -ss100m  ... 
[svxii@b0dasvx01 PSfiles]$ 
</pre> 
 
<p>All that is missing is the pipi <em>(pronounced pe-pe)</em></p>
<!-- Author: Ankush -->
<!-- Comment: Mon Oct 16 13;21;19 comment by...Ankush -->
<p>While powering up the detector, the PS-GUI crashed.  The lines are the top are the errors returned by java.</p>

<!-- Comment: Mon Oct 16 13;24;21 comment by...Ankush -->
<p>Just for fun, I rebooted SVXINTER and restarted IMON in addition to restarting our <em>glorious</em> PS-GUI.</p>


<!-- Date: Mon Oct 16 14:13:08 2006 -->
<h3>RT Server restarted</h3> 
 
<p>The RT server had to be restarted.  No problems for us.  I ran spy-spy.pl again and only init-spy had to be restarted.</p>
<!-- Author: Ankush -->


<!-- Date: Mon Oct 16 14:23:10 2006 -->
<h3><font color="red">Silicon is back to STANDBY</font></h3> 
 
<p>The Silicon is back to STANDBY with all ladders.  The temperature of CCE1 is now at 16.60°C and holding steady.  As we still have the air leak, we must continue to maintain vilgilence  over the bad ISL cooling line.</p> 
 
<p>I have taken the detector through COLDSTART a few times through ACTIVATE. It runs for a bit but we are still plagued by the BUSY timeouts problems.</p> 
 
<!-- Author: Ankush -->


<!-- Date: Mon Oct 16 15:12:22 2006 -->
<h3>Silicon COSMICS</h3> 
 
<p>We are now running Silicon COSMICs!!!  All the ladder looks fine now.  e052 was yellow initially but looks OK now.  I also had some fun with the new CSL...fortunatly Frank Chelbana is also the current SciCo.</p> 
 
<p>If you use siDumpNow, the shell script defines the enviroment variable <pre>CSLHOSTNAME=b0dau32.fnal.gov</pre>.  This is the <em>old</em> CSL receiver node.  The <em>new</em> CSL receiver node is now <pre>b0csl20.fnal.gov</pre>.  I have edited the shell script to point to this node.  However if we revert back to the <em>old</em> CSL host, one should make the appropiate changes.</p>
<!-- Author: Ankush -->
<!-- Comment: Mon Oct 16 15;14;01 comment by...Ankush -->
<h4>...and Silicon is ON</h4>

<p>There are some bias pinkys from the Micron ladders.  But they'll go back to normal after a few days of being ON.</p>

<!-- Date: Mon Oct 16 17:16:58 2006 -->
Entered in Silicon database: <ul>
<li>Ladder: SB0W9L2 
<li>problem n: 1775 
<li>Status: needs_observation
<li>Type: Chip_capid
<li>Action: Diagnosis_update
<li>entered by: sasha 
<li>description is: This ladder is OK in both RA (5K events) and NN (1K events) modes. So, it looks like the previous incident of 'pipeline out of sync' was a single event of ladder madness. Let's keep an eye on this ladder for ~2 weeks with data before declaring it fixed.   
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B0W9&layer=L2">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Mon Oct 16 17:27:19 2006 -->
Entered in Silicon database: <ul>
<li>Ladder: SB0W5L3 
<li>problem n: 1654 
<li>Status: needs_observation
<li>Type: Chip_other
<li>Action: Diagnosis_update
<li>entered by: sasha 
<li>description is: Init readback is OK. Need to check this ladder after a week with data before removing the 'readback' mask. 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B0W5&layer=L3">report</a></ul>
<!-- Author: Problem DB -->



<!-- Date: Mon Oct 16 17:36:39 2006 -->
<center><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-10081&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-10081' width='300'></a><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-10083&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-10083' width='300'></a><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-10082&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-10082' width='300'></a><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-10084&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-10084' width='300'></a></center>
<!-- Author: Ankush -->
<!-- Comment: Mon Oct 16 17;39;26 comment by...Ankush -->
<h3>Run 225118: Post-Bore work Silicon COSMICs</h3>

<p>Here are the SVXMon plots after the bore work.  All the ladders were including f401 & f403 were in this COSMICs run. The run was for 1.5hrs.  From these plots the Silicon looks fine.  But I should cross-check with the reference plots taken just before the plug pull.</p>


<!-- Date: Mon Oct 16 17:40:32 2006 -->
<table><tr><td><a href=/elog/notebooks/silicon/Mon_Oct_16_2006_174023.ps align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-10086  align='top'></a></td><td>I ran e280 in SVXDAQ and found that it was giving 100% rate of bit5 low. See picture. This ladder needs a fiber swap test.</td></tr></table>
<!-- Author: sasha -->

<!-- Date: Mon Oct 16 17:44:42 2006 -->
Entered in Silicon database: <ul>
<li>Ladder: SB2W8L0 
<li>problem n: 1497 
<li>Status: needs_work
<li>Type: Chip_bit_error
<li>Action: Diagnosis_update
<li>entered by: sasha 
<li>description is: This ladder gave bit5 low errors during quiet time studies with SVXDAQ (<a href= 'http://www-cdfonline.fnal.gov/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=323&frame=2&anchor=17:40:32'> see plot</a>). It needs a fiber swap.     
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B2W8&layer=L0">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Mon Oct 16 17:51:23 2006 -->
Entered in Silicon database: <ul>
<li>Ladder: SB0W8L4 
<li>problem n: 1638 
<li>Status: needs_observation
<li>Type: AVDD
<li>Action: Diagnosis_update
<li>entered by: sasha 
<li>description is: This ladder gave no data at all during last detector checkout on 10/12/06. However, the detector was warm at that time. After the detector was cooled down, I have ran this ladder again without any problems. So, it gives data and inits OK. We need to continue observations for ~2 weeks with data before removing 'readback' mask and closing this thread. 
<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: Mon Oct 16 17:57:39 2006 -->
I tested e264 in SVXDAQ after the detector was cooled down. This ladder is OK. It was noticed last week (<a href= 
'http://www-cdfonline.fnal.gov/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=322&frame=2&anchor=22:36:04'>see here</a>), that ladder was giving errors. This was very likely related to temperature.
<!-- Author: sasha -->

<!-- Date: Mon Oct 16 18:28:07 2006 -->
Entered in Silicon database: <ul>
<li>Ladder: IB5W1L1 
<li>problem n: 1647 
<li>Status: fixed
<li>Type: AVDD
<li>Action: IMON_limits
<li>entered by: amitra 
<li>description is:  <p>AVDD went up again.</p><table border=1>
<tr><th>IMON LIMITS</th><th>Old</th><th>New</th></tr>
<tr><td><b>Nominal</b></td><td>755.0</td><td>1540.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>805.0</td><td>1550</td></tr></table> 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=ISL&wedge=B5W1&layer=L1">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Mon Oct 16 18:32:15 2006 -->
Entered in Silicon database: <ul>
<li>Ladder: IB5W1L1 
<li>problem n: 1647 
<li>Status: fixed
<li>Type: AVDD
<li>Action: IMON_limits
<li>entered by: amitra 
<li>description is: <p>Screwed up previous entry..here is the correct entry</p><table border=1>
<tr><th>IMON LIMITS</th><th>Old</th><th>New</th></tr>
<tr><td><b>Nominal</b></td><td>	755.0</td><td>1535.0</td></tr>
<tr><td><b>Lower</b></td><td>705.0</td><td>1480.0</td></tr>
<tr><td><b>Upper</b></td><td>805.0</td><td>1580.0</td></tr></table> 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=ISL&wedge=B5W1&layer=L1">report</a></ul>
<!-- Author: Problem DB -->



<!-- Date: Mon Oct 16 19:09:26 2006 -->
<h3>Even more COSMICS</h3> 
 
<p>As part of CSL test and general detector shake-down, the Silicon  has been included in an overnight COSMICs run. </p>
<!-- Author: Ankush -->


<!-- Date: Mon Oct 16 22:57:30 2006 -->
I called 2080 because the pager was off (the number was "24", is that the code for low batteries?). Silicon was on stanby and out of cosmics because of previous SVT problems. I Oked the request  
to pu it back in. After a while I got paged because of the  
dominant red on 
 <a href= 
'http://www-cdfonline.fnal.gov/cgi/internal/elog/elog.pl?nb=2006&action=copyentry&page=773&time=22:37:20.495'> 
SVXMon </a>. 
I asked them to compare to the previous entry by Ankush on this e-log.
<!-- Author: Ignacio -->


<!-- Date: Tue Oct 17 05:56:56 2006 -->
I got paged becasue all 4 racks in the collision hall had turned 
<a href= 
'http://www-cdfonline.fnal.gov/cgi/internal/elog/elog.pl?nb=2006&action=copyentry&page=774&time=04:19:40.615'> 
 off</a>. I told them to exclude silicon, called Ankush  an drove in. 
After having a look and not finding anything obvious for a cooling trip we asked the cryo to repower the crates. They are having  
problems with this. They cannot reset the racks from IFIX but there are not QUADLOG errors to resest. Since this is taking a while, cooling jennifer was paged to warm up ISL so that we do not disturb COT.   
<!-- Author: Ankus/Ignacio -->
<!-- Comment: Tue Oct 17 06;07;31 comment by...Jennifer/Ankush/Ignacio -->
Jennifer has set the ISL cooling temperature to 10 C, SVX temperature to -6. Hopefully COT will be hapier now. 
Just after this is done, a solenoid trip alarm comes off. 

<!-- Comment: Tue Oct 17 06;51;38 comment by...Jennifer/Ankush/Ignacio -->
Our current understanding of the sequence of events is:
<li> A temperature sensor (ISL East return) of the quadlog is giving wild temeperatures. This caused the quadlog to switch off all 4 svx racks in the collision hall. They are considering adding a resistor basically ignoring the sensor.</li>
<li> Other (presumably unrelated failure) is a failure in a CLC fan  ("muffin fan") that is supposed to remove eventual concentrations of flammable gas. This failure caused the solenoid trip and switched off collision racks in the collision hall and several racks is the first floor.</li>

Cryo and Dervin are working on this. They may need a sniffer in order to get in the collision hall. 


<!-- Date: Tue Oct 17 07:00:26 2006 -->
<table border=0><td><tr><td bgcolor=#e0e030><h3><font color="red"> 
Q: WHY WERE THE PS-CAEN-OFF ALARMS IGNORED IN iFIX ???????? 
</font> 
</h3></td></tr></td></table>
<!-- Author: Ankush -->


<!-- Date: Tue Oct 17 07:29:38 2006 -->
<center><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-10087&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-10087' width='300'></a><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-10088&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-10088' width='300'></a></center>
<!-- Author: ISL and SVX Alcove temps. My mini-warm-up went just fine. ISL now sits at 10&deg;C SVX at -6&deg;C --Jennifer :-) -->


<!-- Date: Tue Oct 17 07:44:58 2006 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-10089&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-10089  width='300' align='top'></a></td><td>Broken temperature sensor (or flaky connection?) for L00 East Return. This sensor is used in the QuadLog interlock exclusively. If the temperature is above 25°C, the racks will trip. Note that the flow will not trip, as the QuadLog interlock would only shut down a pneumatic valve to the entire detector if the pressure is greater than 18 psi.</td></tr></table>
<!-- Author: Ulrich -->


<!-- Date: Tue Oct 17 07:46:46 2006 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-10090&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-10090  width='300' align='top'></a></td><td>Hey, it appears that we *can* see this temperature reading in iFix (check out the aqua "gonzo" temperature reading).</td></tr></table>
<!-- Author: Jennifer -) -->
<!-- Comment: Tue Oct 17 07;47;21 comment by...Jennifer :-) -->
Haha, woops.


<!-- Date: Tue Oct 17 07:57:25 2006 -->
<table border=0><td><tr><td bgcolor=#e0e030><h2>Notice! I have turned off PS Alarm!</h2> 
<p> 
"Yes... this is how your do it" --Ankush</td></tr></td></table>
<!-- Author: Jennifer :-) for the Sillys -->


<!-- Date: Tue Oct 17 08:34:58 2006 -->
b0sili01 is making a painfull high pitch noise for already at least 24 h. It does not sound right. Maybe related to the RAID?  
I would reboot the machine  but Ankush wanted  experts to have a look to it...  
<!-- Author: Ignacio -->
<!-- Comment: Tue Oct 17 14;49;16 comment by...Ignacio -->
<pre>Beep was related to the PC box being not completely closed. 
</pre>
<!-- Date: Tue Oct 17 08:51:25 2006 -->
<h3>Faulty sensor temporarily bypassed</h3> 
Warren and Wayne bypassed the faulty temperature sensor for the East L00 Return with a spare sensor in the wiring cabinet on the first floor. Now the QuadLog interlock is happy again. We showed that we can power on one of the collision hall racks, but keep the rest of them off until we have fixed the sensor.
<!-- Author: Ulrich -->



<!-- Date: Tue Oct 17 15:48:50 2006 -->
Reacks are powered. Detector back on standby.
<!-- Author: Ignacio/Ankush -->
<!-- Comment: Tue Oct 17 21;38;42 comment by...Ignacio -->
For the recors, we had to reset_crate b0fib05 twice.
<!-- Date: Tue Oct 17 16:16:13 2006 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-10092&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-10092  width='300' align='top'></a></td><td><h3>ISL CCE1 Cooling line</h3> 
 
<p>After Ulrich et al fixed the bad L00 RTD, the detector was powered up.  All the ladder came up and the ISL CCE1 cooling line settled around 17.09°C.</p>  
 
</td></tr></table>
<!-- Author: Ankush -->
<!-- Comment: Tue Oct 17 16;54;28 comment by...Ulrich -->
Before turning on the detector, I lowered the SVX and ISL temperature set points to -10°Cand 6°C respectively. I also undid the (undocumented!) changes to the PLC trip limits and reset the iFix warning/alarm limits. Now everything is out of alarm and there are no silenced alarms other than the SVX conductivity (which always goes haywire if we warm up things).
<!-- Date: Tue Oct 17 16:53:14 2006 -->
<center><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-10093&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-10093' width='300'></a></center>
<!-- Author: Ankush -->
<!-- Comment: Tue Oct 17 17;13;07 comment by...Ankush -->
<h3>Resetting Temperature Trip Limits</h3>

<p>When the detector was warmed up in the morning, Jennifer increased the trip limits.</p>

<p>When the detector was cooled back down, the Temperature Trip were not reset to their original values.  So ISL claimed it was too cold in iFIX.</p>

<p>The snapshot is here is for reference for running SVX at -10°C and ISL at +6°C.</p>



<!-- Comment: Tue Oct 17 17;25;29 comment by...Ankush -->
<table border=0><td><tr><td bgcolor=#e0e030><h3>All alarms are enabled</h3>

<p>All the CAEN iFIX alarms have been enabled.  Do <b>NOT</b> disable any alarms....even if the alphanumeric pager annoys you.  If you have to disable an alarm, please document this in the elog as a reminder to yourself and to alert the other siliconeers.</p></td></tr></td></table>


<!-- Comment: Tue Oct 17 17;30;14 comment by...Ankush -->
<h3>Silicon is ON</h3>

<p>I have just put Silicon to ON to see what happens to the bias currents.  No surprise, the Micron ladders are giving PINKYs</p>.
<!-- Comment: Tue Oct 17 18;56;04 comment by...Ankush -->
<h3>Silicon back to STANDBY</h3>

<!-- Date: Tue Oct 17 17:28:51 2006 -->
<h3>Silicon Evening Plans</h3> 
 
<p>As quite a bit of work has gone on today, I would like Silicon to be included in an overnight COSMICs run.  The idea is to shake down the system and check everything is still functioning.</p>  
<!-- Author: Ankush -->



<!-- Date: Tue Oct 17 17:49:19 2006 -->
<h3>The Tale of the Repair of the East L00 Return Temperature Sensor</h3> 
 
At around 3:45 this morning, a QuadLog trip shut off all Silicon racks in the collision hall. The trip was caused by a faulty temperature sensor used in the QuadLog interlock. The sensor measures the temperature of the East L00 return line and is situated right above the manual return valve (SVX-MV-L00ERET). In the QuadLog logic, the racks are tripped if the temperature in any return line is above 25°C. The sensor had shown first symptoms of a problem around 18:30 last night (reading -219°C, i.e. open connection). At the time of the trip, the reading jumped up to >900°C (maximum reading) and took the racks out. 
<p> 
As the sensors are 3-wire PT100 RTD sensors, you expect around 110 Ω (at room temperature) between the two sides of the wire (red-black or red-white) and no resistance between the same wire type (black-black or black-white). Note that the RTD must not be connected to a readout module to get a meaningful measure of the resistance. Otherwise, the excitation voltages of the readout module and the DVM interfere. Note also that the QuadLog sensors are not fed back into our Siemens PLC. The sensor readings are accessible from the iFix database on CDF S3.  
<p> 
To temporarily clear the QuadLog error, we hooked up a spare RTD sensor in the 1st floor wiring cabinet. At that point we were able to switch on the racks again. We left all but one off because of the imminent work on the sensor. The re-wiring also confirmed that the error was downstream of the wiring cabinet. The resistance between the black and the red wire was more than 1 MΩ. Next we went to the NE wire terminal close to the East SVX manifold, disconnected the wire there and measured again the resistance, closer to the sensor. The result was the same. We even cut the wire to the sensor as close as possible to the sensor, but the result was still the same. Conclusion: it was not the wiring but the sensor which went bad. 
<p> 
As a preparation for the cooling work we shut down flow to L00 (East and West). SVX and ISL stayed on. The next step was to find out which kind of probe is being used in the system. The name is MINCO S604 PD25 Z108 S(C), a 100 Ω Platinum 385 probe with a length of 2.5 inch, 3/16 inch diameter with 3 leads. We found spare probes of this kind in the Silicon cooling cabinet. When we tried to replace the broken probe, we did not manage to remove it. We suspect that the probe got slightly deformed during installation and got stuck in the insert. The probe actually broke right at the ferrel, and we could not remove the rest. So we decided to close the insert with a cap and install a new temperature probe further upstream. 
<p> 
In theory, installing the new probe was trivial: cut the cooling pipe (poly-flow), insert a T with a temperature probe, and close it up again. In reality, it turned out to be not that easy. Here is what went wrong: 
<ul> 
<li>SVX is different in many aspects, also in the cooling! Whenever possible, they took non-standard gauges. For example, the poly-flow tubes are 5/8 inch, not 1/2. Another example: the probe has a diameter of 3/16 inch, not 1/4. So it took us a while to find a 5/8 inch T and something to interface it to a 3/16 inch probe. We ended up welding a 1/4 inch piece to a 5/8 T and expanding the bore to fit a 1/4 inch temperature probe in it. The probe we use now is a MINCO S603 PD80 Z36 T(C), i.e. a  100 Ω Platinum 385 probe, 8 inches long and 1/4 inch in diameter.</li> 
<li>L00 East and West are connected. When we cut the poly-flow, we destroyed the vacuum in L00. However, we did not close the manual return valve on the West side. As a consequence, the vacuum got worse for SVX, and SVX tripped on low flow. We realized this rather quickly, closed the West return valve, and re-established flow to SVX within minutes. 
</ul> 
After both the cap and the new probe were installed and insulated, 
we evacuated L00 again and  
performed a quick rate of rise test. The L00 vacuum was at least as good as during the last test (0.1 psi/min). During the evacuation, we tripped the SVX flows once more, probably because the vacuum got bad again for a while. We wired up the new sensor in the 1st floor without problems. The new probe reads reasonable values. The only funny thing is that the wire between the collision hall and the 1st floor has a resistance of as much as 7 Ω. This may change the temperature reading slightly 
 
<p> 
A big thanks to the sensor debugging crew (Del Allspach, Dean Beckner, Warren Bowman, Andy Hocker, and Wayne Waldon) and the Silicon crew (Jennifer, Ankush, Jose, Ignacio).  
<!-- Author: Ulrich -->
<!-- Comment: Tue Oct 17 18;22;35 comment by...Ankush & Ulrich -->
We just did a visual inspection of the manifolds. Everything tight so far.
<!-- Date: Tue Oct 17 18:00:34 2006 -->
<h3>VTM Harvesting</h3> 
 
<p>We are going to add a new VRB crate (SVX09) to help the L2/EVB.  However, it would be best to maintain a <em>parallel</em> setup of the current and <em>new</em> VRB setup.</p> 
 
<p>In order to accomdate a <em>parallel</em> setup, we need extra VTMs.  So with SVTG-Jahred I harvested the L00 VTMs from SVT...alas we will never put L00 into SVT.</p>
<!-- Author: Ankush -->


<!-- Date: Tue Oct 17 18:02:31 2006 -->
<center><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-10094&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-10095' ></a><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-10096&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-10097' ></a><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-10098&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-10099' ></a><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-10100&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-10101' ></a><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-10102&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-10103' ></a></center>
<!-- Author: Ulrich -->
<!-- Comment: Tue Oct 17 18;05;15 comment by...Ulrich -->
<h3>Sensor Picture Gallery</h3>
From left to right: cut East L00 return line, insert for temperature probe (after removal of old probe), newly installed T with new probe, Warren installing new probe, final overview.





<!-- Date: Tue Oct 17 21:56:59 2006 -->
<h3>3 & 4 wire resistance measurements</h3> 
 
<p>Some people have been asking me about how we do our temperature measurements from the RTDs.  You can download a little primer from <a href="http://www.omega.com/temperature/z/pdf/z033-035.pdf">here</a>. 
</p>
<!-- Author: Ankush -->


<!-- Date: Tue Oct 17 22:03:37 2006 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-10104&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-10104  width='300' align='top'></a></td><td><h3>Repeated Stuck Cell ID for SB0W1L2</h3> 
 
<p>During the COSMICs run, SVXMon was reporting repeared stuck Cell-ID the Z-side of SB0W1L2.  Looking at the PDB, this ladder is a AVDD2 victim from the Beam Incident.  The Z-side has been noted for being flaky.  However in recents runs, it seems to be running without the CAP-ID problem.  At the moment this ladder seems OK again.</p> 
 
<p>Whenever we get back to data taking, it would be prudent to have a look at this ladder.</p></td></tr></table>
<!-- Author: Ankush -->


<!-- Date: Tue Oct 17 22:13:45 2006 -->
<center><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-10105&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-10105' width='300'></a><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-10106&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-10106' width='300'></a></center>
<!-- Author: Ankush -->
<!-- Comment: Tue Oct 17 22;29;03 comment by...Ankush -->
<h3>Effect of a single large VRB upon L2A</h3>

<p>The graphs here are plotting the data from the <a href="http://www-cdfonline.fnal.gov/cgi/elog/elog.pl?nb=2006&action=view&page=760&frame=2&anchor=16:00:30.620">
Event Size test</a> done last week.  It also describes the details of the test. The main point was they artificially inflated the event size of VRB05 and so increase the strain upon one EVB.  This is supposed to simulate the conditions we run at high lumi where the ISL/L00 events size per EVB is significantly larger than other EVBs.</p>

<p>The graph on the left plots two quantities as a variation of L2A rate.  The solid lines are the variation of DeadTime (left-axis) with L2A rate.  The dashed lines are the Data rates with L2A.   The different colours correspond to different event size of the test VRB VRB05.</p>

<p>The general feature is the deadtime intially grows slowly with L2A and then suddenly increases....much like an exponential..(looks a lot like a diode IV curve).  This feature has been called the EVB-wall, or deadtime wall. The L2A rate where we hit this deadtime wall depends on the VRB 05 event size.  A smaller event size pushed the deadtime wall to a higher L2A rate. This is one of the motivations for adding the extra ISL/L00 VRB crate to reduce the load per EVB</p>

<p>The right hand graph shows the L2A rate as a function of the VRB05 event size.  the different lines are for different deadtimes.  The interesting feature is there is little dependance  upon the deadtime.  But it does show the L2A has a dependance upon VRB05 size.</p>

<!-- Comment: Tue Oct 17 22;56;31 comment by...Ignacio -->
<pre>So what is the maximum event size we are allowed, or, in other words, what is the maximum L2A rate they are aiming to?
</pre>

<!-- Comment: Tue Oct 17 23;23;40 comment by...Ankush -->
<p>The goal is to have a 1kHz L2A for luminosities upto 300E30.  In practice this may not be feasable but we can at least try.</p>


<!-- Date: Tue Oct 17 23:33:00 2006 -->
<h3>SVX09 TWiki Page</h3> 
 
<p>To document what we are doing and how we are going to proceed, I have started a TWiki page.  You can find it at:</p> 
 
<a href="http://b0sili01.fnal.gov/cgi-bin/TWiki/bin/view/Silicon/NewSiliconCrate"> 
http://b0sili01.fnal.gov/cgi-bin/TWiki/bin/view/Silicon/NewSiliconCrate</a>
<!-- Author: Ankush -->


<!-- Date: Wed Oct 18 08:44:02 2006 -->
<h3>Successfull overnight running</h3> 
 
<p>Silicon ran overnight with no problems.  Even the repeated CAP-ID error for e012 dided down during the night.  It also got rid of the inital Micron BIAS pinkys.</p> 
 
<p>I hvae now asked the shift crew to take silicon out and silicon has been put back to STANDBY.  So we can use it for our needs.</p>
<!-- Author: Ankush -->


<!-- Date: Wed Oct 18 11:31:32 2006 -->
<h3>SVX09 is alive !!</h3> 
 
<p>Jamie installed the communication cables for the EVB and the MVME.  SVX09 is alive!!</p> 
 
<pre> 
<svxii@b0gateway>ping svx09.fnal.gov 
ping: unknown host svx09.fnal.gov 
<svxii@b0gateway>ping b0svx09.fnal.gov 
PING b0svx09.fnal.gov (131.225.237.157) 56(84) bytes of data. 
64 bytes from b0svx09.fnal.gov (131.225.237.157): icmp_seq=0 ttl=254 time=0.591 ms 
64 bytes from b0svx09.fnal.gov (131.225.237.157): icmp_seq=1 ttl=254 time=0.262 ms 
64 bytes from b0svx09.fnal.gov (131.225.237.157): icmp_seq=2 ttl=254 time=0.273 ms 
64 bytes from b0svx09.fnal.gov (131.225.237.157): icmp_seq=3 ttl=254 time=0.280 ms 
 
--- b0svx09.fnal.gov ping statistics --- 
4 packets transmitted, 4 received, 0% packet loss, time 3004ms 
rtt min/avg/max/mdev = 0.262/0.351/0.591/0.139 ms, pipe 2 
<svxii@b0gateway>vxlogin b0svx09.fnal.gov 
spawn rsh b0svx09.fnal.gov 
b0svx09.fnal.gov: Connection refused 
trying normal rlogin (/usr/bin/rlogin)  WARNING: NO ENCRYPTION! 
 
VxWorks login: vxworks 
Password: 
 
b0svx09-> i 
 
  NAME        ENTRY       TID    PRI   STATUS      PC       SP     ERRNO  DELAY 
---------- ------------ -------- --- ---------- -------- -------- ------- ----- 
tExcTask   excTask       7bfe708   0 PEND         2959d0  7bfe630       0     0 
tNetTask   netTask       7bf6f28   1 PEND         279ab8  7bf6e78       0     0 
tPortmapd  portmapd      7bf21a0   1 PEND         279ab8  7bf2030      16     0 
tRlogOutTasrlogOutTask   7930e30   2 PEND         279ab8  7930ca8       0     0 
tRlogInTaskrlogInTask    792c450   2 PEND         279ab8  792c228       0     0 
tShell     shell         7b78928   5 READY        27d47c  7b778f0  320002     0 
tRlogind   rlogind       7bf3730  15 PEND         279ab8  7bf3370       0     0 
t1         VISIONserver  7bdca40 100 PEND         279ab8  7bdc910       0     0 
t2         ROBINserver   7bd74e0 100 PEND         279ab8  7bd73a0       0     0 
Messenger  FER_messenge  7bb74c0 200 PEND+T       279ab8  7bb7230  3d0002     4 
rtlm_main  rtlm_main     7bd24b8 220 PEND         279ab8  7bd2378       0     0 
Mon_III    FER_monitorI  7967da8 220 DELAY        27ca30  7967cf8  1c0001    31 
rtlm_sessiortlm_session  7b58ef0 225 PEND         279ab8  7b58d10       0     0 
tLogTask   logTask       7bfbd90 250 PEND         2959d0  7bfbcc8       0     0 
value = 0 = 0x0 
b0svx09-> logout 
 
rlogin: connection closed. 
<svxii@b0gateway>vxcom b0svx09 
 
Escape sequence is ^A. (ctrl-A period) 
One moment please... 
 
 
 
 
b0svx09-> i 
 
  NAME        ENTRY       TID    PRI   STATUS      PC       SP     ERRNO  DELAY 
---------- ------------ -------- --- ---------- -------- -------- ------- ----- 
tExcTask   excTask       7bfe708   0 PEND         2959d0  7bfe630       0     0 
tNetTask   netTask       7bf6f28   1 PEND         279ab8  7bf6e78       0     0 
tPortmapd  portmapd      7bf21a0   1 PEND         279ab8  7bf2030      16     0 
tShell     shell         7b78928   5 READY        27d47c  7b785b0  320002     0 
tRlogind   rlogind       7bf3730  15 PEND         279ab8  7bf3370       0     0 
t1         VISIONserver  7bdca40 100 PEND         279ab8  7bdc910       0     0 
t2         ROBINserver   7bd74e0 100 PEND         279ab8  7bd73a0       0     0 
Messenger  FER_messenge  7bb74c0 200 PEND+T       279ab8  7bb7230  3d0002     2 
rtlm_main  rtlm_main     7bd24b8 220 PEND         279ab8  7bd2378       0     0 
Mon_III    FER_monitorI  7967da8 220 DELAY        27ca30  7967cf8  1c0001    23 
rtlm_sessiortlm_session  7b58ef0 225 PEND         279ab8  7b58d10       0     0 
tLogTask   logTask       7bfbd90 250 PEND         2959d0  7bfbcc8       0     0 
value = 0 = 0x0 
b0svx09-> Connection to b0serial04 closed. 
<svxii@b0gateway> 
</pre>
<!-- Author: Ankush -->
<!-- Comment: Wed Oct 18 11;42;10 comment by...Ankush -->
<h4>...even better I think it knows its a silicon crate</h4>

<pre>
b0svx09-> reboot
Attaching network interface dc0... done.
Attaching network interface lo0... done.

Adding 4659 symbols for standalone.


 ]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]
 ]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]
 ]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]
      ]]]]]]]]]]]  ]]]]     ]]]]]]]]]]       ]]              ]]]]         (R)
 ]     ]]]]]]]]]  ]]]]]]     ]]]]]]]]       ]]               ]]]]
 ]]     ]]]]]]]  ]]]]]]]]     ]]]]]] ]     ]]                ]]]]
 ]]]     ]]]]] ]    ]]]  ]     ]]]] ]]]   ]]]]]]]]]  ]]]] ]] ]]]]  ]]   ]]]]]
 ]]]]     ]]]  ]]    ]  ]]]     ]] ]]]]] ]]]]]]   ]] ]]]]]]] ]]]] ]]   ]]]]
 ]]]]]     ]  ]]]]     ]]]]]      ]]]]]]]] ]]]]   ]] ]]]]    ]]]]]]]    ]]]]
 ]]]]]]      ]]]]]     ]]]]]]    ]  ]]]]]  ]]]]   ]] ]]]]    ]]]]]]]]    ]]]]
 ]]]]]]]    ]]]]]  ]    ]]]]]]  ]    ]]]   ]]]]   ]] ]]]]    ]]]] ]]]]    ]]]]
 ]]]]]]]]  ]]]]]  ]]]    ]]]]]]]      ]     ]]]]]]]  ]]]]    ]]]]  ]]]] ]]]]]
 ]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]
 ]]]]]]]]]]]]]]]]]]]]]]]]]]]]]       Development System
 ]]]]]]]]]]]]]]]]]]]]]]]]]]]]
 ]]]]]]]]]]]]]]]]]]]]]]]]]]]       VxWorks version 5.3.1
 ]]]]]]]]]]]]]]]]]]]]]]]]]]       KERNEL: WIND version 2.5
 ]]]]]]]]]]]]]]]]]]]]]]]]]       Copyright Wind River Systems, Inc., 1984-1997

                               CPU: Motorola MVME2300 - MPC 604r.  Processor #1.
                              Memory Size: 0x8000000.  BSP version 1.1/4b.

Executing startup script boot/front-end/startup.cdf ...
# CDF specific initialization
#
cdfInit()
System booted at WED OCT 18 10:39:37 2006

Initializing CDF kernel version 8.20 created Oct  6 2006 15:06:29
I think you are b0svx09.fnal.gov

task spawned: id = 0x7bdca40, name = t1
FISION_comp_path is /cdf/onln/code/cdfprod/fision/v2_17/VxWorks-5.3/ppc/MVME2301
ROBIN_repository is /cdf/onln/code/cdfprod/svxii/devel/server/lib/VxWorks-5.3/ppc:/cdf/onln/code/cdfprod/vrb/devel/server/lib/VxWorks-5.3/ppc:/cdf/onln/code/cdfprod/cdfvme_common/v3_0a/server/lib/VxWorks-5.3/ppc:/cdf/onln/code/cdfprod/vrbtest/current/VxWorks-5.3/ppc
task spawned: id = 0x7bd74e0, name = t2
value = 0 = 0x0
#
cd "~vxworks/boot/front-end"
value = 0 = 0x0
< ${CUSTOM_STARTUP}
# Custom startup for SVX Crates

#Add fndaub to get firmware Commented out for security 10/18/01 SCN
#hostAdd "fndaub", "131.225.80.191"
#hostAdd "b0dap64", "131.225.236.174"
#nfsMount "fndaub", "/home/t2/vxworks/jam", "/jam/data"
#hostAdd "b0dap30", "131.225.236.5"

#Allow FISION/ROBIN Access from trailers Subnets 233, 103, 242
FISIONauthAdd( 0xffffff00, 0x83e16700 )
value = 0 = 0x0
FISIONauthAdd( 0xffffff00, 0x83e1e900 )
value = 0 = 0x0
FISIONauthAdd( 0xffffff00, 0x83e1f200 )
value = 0 = 0x0

ROBINauthAdd( 0xffffff00, 0x83e16700 )
value = 0 = 0x0
ROBINauthAdd( 0xffffff00, 0x83e1e900 )
value = 0 = 0x0
ROBINauthAdd( 0xffffff00, 0x83e1f200)
value = 0 = 0x0


# Load Run Control Modules (if selected in table file)

< ${RC_LOAD}
# Run Control Loader for SVX Crates
hostAdd("b0server01","131.225.236.173")
value = -1 = 0xffffffff = boardH + 0xffcd078f
#Add in FER
#ld < ${FER_DIR}/${VXB_DEST_ENV}/${VXB_DEST_ARCH}/FER_Smart
ld < ${FER_DIR}/${VXB_DEST_ENV}/${VXB_DEST_ARCH_FER}/FER_SmartBase
value = 129903080 = 0x7be29e8 = XFT_DUMP_PATTERN + 0x5f0
# Load cdfvme modules, as rc needs them on all crates
ld < ${SVXII_DIR}/server/lib/${VXB_DEST_ENV}/${VXB_DEST_ARCH}/SrcVme
value = 129417424 = 0x7b6c0d0 = src_debug + 0xd64
ld < ${VRB_DIR}/server/lib/${VXB_DEST_ENV}/${VXB_DEST_ARCH}/VrbVme
value = 129418496 = 0x7b6c500
ld < ${SVXII_DIR}/server/lib/${VXB_DEST_ENV}/${VXB_DEST_ARCH}/FfoVme
value = 129495304 = 0x7b7f108 = FFO + 0xd90
ld < ${SVXII_DIR}/server/lib/${VXB_DEST_ENV}/${VXB_DEST_ARCH}/FibVme
value = 129417936 = 0x7b6c2d0 = src_debug + 0xf64
ld < ${SVXII_DIR}/server/lib/${VXB_DEST_ENV}/${VXB_DEST_ARCH}/SvxCrateVme
value = 129156920 = 0x7b2c738 = _version + 0x198
ld < ${SVXII_DIR}/server/lib/${VXB_DEST_ENV}/${VXB_DEST_ARCH}/SiGBVme
value = 129743472 = 0x7bbba70 = SIGB + 0x9c4
ld < ${SVXII_DIR}/si_ss/server/lib/${VXB_DEST_ENV}/${VXB_DEST_ARCH}/rc_SVX
value = 129339640 = 0x7b590f8
# Temporary code for the CCC - sgr
ld < /cdf/onln/home/gris/code/c/ccc/tstsvx1/ccc1.o
value = 128529288 = 0x7a93388
ld < /cdf/onln/home/gris/code/c/ccc/tstsvx1/lockCCC.o
value = 128527816 = 0x7a92dc8 = ADDRESS + 0xf40
#
# Set the clock Speed
#
svx_setClkSpeed

 crate_wait delay resolution:  10 ns
value = 38 = 0x26 = '&'
#
#Spawn FER process
#
sp FER_dummy_setup
task spawned: id = 0x7b78928, name = t3
value = 129468712 = 0x7b78928
# wait a little, then kill the monitoring
#crate_wait(30,0)
#bzero(monconfig, 6)
Found CPU Type 93 with bus speed 60.000000 ns
Terminal could not be reset.  A shell script may be running.

Done executing startup script boot/front-end/startup.cdf
b0svx09-> dummy add 10e5d8; tipcadd 1ed36c, newins 7ff2126c
Connecting to <tcp:localhost> RTlm.
Using tcp protocol.
received connection from 127.0.0.1:1025, socket is 14
Message from RTlm: Connection established.
WARNING: Internal validation failed, file: ipcmsg.c, line 1314WARNING: Internal validation failed, file: ipcmsg.c, line 1314Message from RTlm: License for <RTclient> granted (132 licenses left).
Connecting to project <cdf_daq> on <tcp:b0server05> RTserver.
Using tcp protocol.
Message from RTserver: Connection established.Start subscribing to subject </_b0svx09_129725632>.
Setup SVX Messages
Subject Suffix: /svx/vrb/09
Set up SVX Config Callbacks for /partition-*/configSVX/svx/vrb/09
Set up SVX Map Callbacks for /mapSVX/svx/vrb/09
Subscribed to >>/setPartition/svx/vrb/09<<
Subscribed to >>>/setPartition/svx/vrb/09<<<

b0svx09->
</pre>


<!-- Date: Wed Oct 18 11:49:09 2006 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-10107&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-10108  width='300' align='top'></a></td><td><h3>SVX09 in the HWDB</h3> 
 
<p>Wow....SVX09 is in the HWDB!!</p></td></tr></table>
<!-- Author: Ankush -->


<!-- Date: Wed Oct 18 14:30:37 2006 -->
<pre>Yesterday Ricardo and Jose put 10 VTMs (Fib to VRB and high speed test) to test. The VTM numbers are 560882, 561009, 560744, 560888, 560740, 560736, 560675, 560747, 560938.  VRB 165 passed the high speed test and a test the reset button that  had  been soldered by prep. 

There are 5 good VRB spares (165,136,141,130,183). VRB 150 gave errors yesterday, we will try to reproduce them today. Also have a look to VRB 152. 
 
Today we tested a VFO (SN 015) through high speed and FIB to VRB. All tested OK. This is to populate b0svx09. 
 
</pre>
<!-- Author: Jose/Ricardo/Ignacio -->


<!-- Date: Wed Oct 18 20:33:20 2006 -->
<h3>Some progress with SVX09</h3> 
 
<p>This afternoon we decided to play with SVX09 to see if we could get anything to work. As we did not want to disturb the current set up we took advantage of the L00 fibres which still go through the splitter crate to SVT. We disconnected the SVT fibres for LB1W4/5 (fa4/5) and connected a long patch cord to take the light from the splitter to SVX09. So the FIB of LB1W4/5 now sends its data to a VRB in SVX06; slot 12 and SVX09.</p> 
 
<p>The very first thing we did was to confirm LB1W4/5 can send data to the VRB in svx06; slot 12 with no errors.  In fact it does.  So the new setup has not effected it.</p> 
 
<p>We installed a VFO, VTM and VRB in slot 12 and tried to run SVX09 in SVXDAQ.  We were able to talk to the VRB...it reads out the correct serial number.  We then tried to run SVXDAQ to read out the LB1W4/5.  Now as the data from this FIB is going to 2 VRBs, we were not certain of the outcome. So we decied to turn off the VRB in SVX06, slot 12 as a precaution.</p> 
 
<p>The intial runs were not successful as no data at all was returned. However a reboot of the crate CPU helped.  We could then readout the ladders but we would get persistent pcA(?) byte errors.  A FIB2VRB test highlighted this with a persistenet Bit 1(?) error.</p> 
 
<p>We tried some further test to debug this. 
<ul> 
<li>Swapping fibres on the VTM.  We swapped pairs, swapped within pairs. Nothing helped</li> 
<li>We then added a new VTM, VRB into slot 10 in SVX09 and pulled out the VTM+VRB in slot 12. This did not help either. 
<li>Reseating all the boards in SVX09, including the crate CPU.  This did not help</li> 
</ul> 
 
<p>Whatever we did, the pcA byte errors would persist.  At one point the VRB again did not return any data.  But we were attempting multiple FIB2VRB and SVXDAQ tests.  Taking the detector through COLDSTART fixed the problem and the VRB in SVX09 was returning data again; albeit with the persistent pcA byte errors.</p> 
 
<p>At the end of the day we have some success.  We can talk to the new crate CPU and VRB in SVX09 through VME.  Also the light to the VTM from the splitter rack is sufficient.  The LED on the VTM is on and the GLINKS can be SYNCHED.  However the bad point is we persistently see pcA byte errors which we cannot get rid of.</p> 
 
<p>Tomorrow, we plan to talk to Bill Badgett to add a VRB card entry for SVX09 in the HWDB.  Then we can use the chip editor to generate the configuration for SVXDAQ.</p> 
  
<!-- Author: Ankush, Jose, Ignacio, Mark -->
<!-- Comment: Thu Oct 19 07;30;18 comment by...SCN -->
My guess is your pcA byte errors are a software thing.  Do you have the link in the link file set correctly? It might be that the software expects a link and you don't have it.  Also, it may be that your data Fib.fifo raw data file does not quite fit the data spec.  You should have 4 bytes of data before the first chip id.  Older versions of the file had only 2 I think.  That might screw it up.  (Of course, you can try the same file on a working Fib/Vrb pair.) 


<!-- Comment: Thu Oct 26 08;46;14 comment by...SCN -->
So, this turned out to be swapped pairs.  Shoulda guessed.  For the record, the FIB only has one input fifo for fake data, so it cannot help but send the same information on all 10 channels, which means it all looks identical in the VRB except for pcA since that is what labels the channels. <br>
One could write an improved Fib2Vrb test which involves different pedestals for the different channels, so you could tell more quickly but that would be a lot of work for little gain.  There's probably other questions about why you only see the first 10 errors in each event, but the thought there was that since the VRB is a FIFO, if drop a byte somewhere, the whole rest of the event is screwed up and you would just spew errors without any info, so we cut it off at some point, which I think was 10.
<!-- Date: Thu Oct 19 08:29:42 2006 -->
Conor took the SCPU out of the test stand crate (which was already powered down) to install it in b0svx09. He powered down that crate and installed the SCPU without problems.
<!-- Author: Ulrich -->


<!-- Date: Thu Oct 19 09:34:03 2006 -->
Dean Beckner and I checked out the East SVX cooling manifold once more, where we replace a temperature sensor on Tuesday. We added some more insulation, and Del Allspach will add a couple of labels and tags. It seems that everything is fine, so we are ready for the IMU steel to be closed.
<!-- Author: Ulrich -->


<!-- Date: Thu Oct 19 09:58:00 2006 -->
<h3>More b0sili** problems</h3> 
 
<p>Mark spotted a problem with b0sili01; it was not seeing /home/cdfsoft.  But b0sili02 could see it.  So we booted off everyone connected....that meant killing some of Oscar's tcsh session....sorry Oscar</p> 
 
<p>...the problem is still beign investigated......</p>
<!-- Author: Ankush -->
<!-- Comment: Thu Oct 19 10;18;40 comment by...Mark -->
Ended up having to reboot b0sili01 to fix this.

<!-- Date: Thu Oct 19 10:30:20 2006 -->
Entered in Silicon database: <ul>
<li>Ladder: IB5W0L0 
<li>problem n: 186 
<li>Status: needs_work
<li>Type: Chip_bit_error
<li>Action: Diagnosis_update
<li>entered by: sasha 
<li>description is: I tested this ladder with SVXDAQ. No errors were observed in RA and NN modes after running 1K events. So, it's likely that the problem may be somehow connected to faulty fib07. Let's see if it goes away after resetting fib07.  
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=ISL&wedge=B5W0&layer=L0">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Thu Oct 19 10:43:38 2006 -->
Entered in Silicon database: <ul>
<li>Ladder: IB2W0L4 
<li>problem n: 1776 
<li>Status: needs_work
<li>Type: Chip_bit_error
<li>Action: Incident
<li>entered by: sasha 
<li>description is: This ladder gives 00_sequence error at 100% rate when running in SVXDAQ. The error seems to be related to bit0 high. It needs a fiber swap.  
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=ISL&wedge=B2W0&layer=L4">report</a></ul>
<!-- Author: Problem DB -->



<!-- Date: Thu Oct 19 11:24:14 2006 -->
<table><tr><td><a href=/elog/notebooks/silicon/Thu_Oct_19_2006_112410.ps align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-10110  align='top'></a></td><td><p>In a previous quiet time study, this ladder gave bit 5 problems.  Now it is running error free....odd indeed.</p></td></tr></table>
<!-- Author: Ankush -->


<!-- Date: Thu Oct 19 11:27:11 2006 -->
<h3>svx09 off for quiet time studies</h3> 
 
<p>Svx09 was interferring with Sasha's detector studies.  So I have turned off the crate for the time being.</p>
<!-- Author: Ankush -->


<!-- Date: Thu Oct 19 13:26:30 2006 -->
<h3>Quiet time studies and Access report</h3> 
 
<p><h4>Quiet time studies:</h4>We used an opportunity to continue quiet time studies and made an access to test some of the problematic ladders. During the quiet time studies, we checked f500, f204, and e132 ladders. f500 had a histrory of weird bit errors, but it was OK in SVXDAQ (both RA and NN). f204 was giving 00_sequence error during detector checkout last week. The error was confirmed with SVXDAQ and it is related to bit0 high. We also tested e132 which was giving problems during checkout, but it is OK now. 
<h4>Access report:</h4> We did a fiber swap for e280 (bit5 low), but the ladder was OK this time. We also resitted an adpater card for fib07. Hopefully, it will help to get read off wedge wide problems which were occuring from time to time.</p>
<!-- Author: Sasha, Ankush, Ignacio -->


<!-- Date: Thu Oct 19 18:47:32 2006 -->
<h3>Status of b0svx09</h3> 
We made some progress with b0svx09 this afternoon after we found out that the fiber we were running to the VRB in that crate was labeled stupidly.  The fibers come in pairs labeled "A" and "B", but "B" on one end is "A" on the other and vis versa.  After fixing this, we were able to run b0svx09 in svxdaq.  The current setup is a single VRB in slot 10 which is connected to b0fib07 slot 17 (fa4/5).  Next we tackled the hardware database.  Bill added VRB card entries for b0svx09 slots 8, 10, 12, 16, 18 and 20.  We marked all but 10 offline and added the correct VRB serial number to the entry for slot 10.  Next we marked the VRB entry in b0svx06 slot 12 offline as that is connected to the same FIB as b0svx09 slot 10.  We started Coldstart, manually adding b0svx09 to the run configuration and were were able to partition, config and run for about 400 events before hitting a Busy TO.  It turns out that the Busy TO is there even without b0svx09, so that looks like another problem.  Tomorrow we will try running with the HEVB which should sidestep the Busy TO problem.  For now we are leaving the new hdwdb and svxdaq settings, so if anyone wants to do a Config in Coldstart, you should manually add VRB_ISL_09.    
<!-- Author: Ankush, Ignacio, Jose, Marcel, Mark -->


<!-- Date: Thu Oct 19 20:14:18 2006 -->
<center><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-10111&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-10112' ></a><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-10113&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-10114' ></a></center>
<!-- Author: Ankush -->
<!-- Comment: Thu Oct 19 20;17;15 comment by...Ankush -->
<h3>SVX09:  Pictures of its current state</h3>

<p>Here are picutres of the front and back of SVX09 at its current state. So far only the VRB/VTM is in slot 10 is plugged in.</p>

<p><em>doesn't it look lovely!!</em></p>  




<!-- Date: Thu Oct 19 20:21:42 2006 -->
<center><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-10115&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-10116' ></a><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-10117&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-10118' ></a><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-10121&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-10122' ></a><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-10119&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-10120' ></a></center>
<!-- Author: Ankush -->
<!-- Comment: Thu Oct 19 20;26;35 comment by...Ankush -->
<h3>L00 in SVT....alas no more</h3>

<p>As part of the plan to add SVX09, I have bypassed the splitters for L00. I guess this officially marks the point that we will no longer have L00 in SVT.  The picutres above are before/after pictures of the L00 splitter tree. There is is still one fibre pair plugged in but this is our test for SVX09.  Once this is removed, the SVT fibres can be uplugged and the L00 splitter rack can be removed.</p>

<p>After bypassing the splitters I ran a FIB2VRB test for all the L00 wedges.  No problems were seen. </p>


<!-- Comment: Thu Oct 26 08;34;24 comment by...SCN -->
<pre>Don't kid yourself.  L00 was removed from the realm of SVT possiblity when we went to two SRCs.  </pre>
<!-- Date: Fri Oct 20 09:00:47 2006 -->
<center><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-10123&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-10123' width='300'></a><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-10124&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-10124' width='300'></a></center>
<!-- Author: Ignacio/Ankush -->
<!-- Comment: Fri Oct 20 09;03;13 comment by...Ignacio/Anksuh -->
Ankush just noticed this fluctuating DVD current on IMON. The voltage has been going down slowly and has became noisy lately.
We'll try to swap the power supply.

<!-- Comment: Fri Oct 20 09;53;06 comment by...Ankush, Jen & Mark -->
<p>Jen and Mark Matthis are on the case now...we will replace the PS</p>


<!-- Date: Fri Oct 20 09:56:18 2006 -->
<h3>ISL: Another Leak</h3> 
This morning, Dervin pointed out that he found a leak at the West ISL manifold, at the Portcard branch. The insulation was all wet, and there was a puddle of something nasty (insulation solved in glycol?) on a galvanized cable tray below that. I had seen that leak before, but it seemed dry the last couple of times I tested it. Dervin was right, this time there was quite a lot of the stuff on the cable tray. So Warren Bowman and I went to the collision hall to investigate. The leak is small enough that we could not see anything obvious after cutting the insulation. Warren realized that both manual valves at the supply side (before and after the branch to the West SVX Portcard) had rather loose packings. He tightened them, and we removed the stuff from the cable tray to put a KimWipe there. We will have to re-visit the place later to see if the leak has disappeared.
<!-- Author: Ulrich -->


<!-- Date: Fri Oct 20 10:12:09 2006 -->
<h3>Multiple jobs going on</h3> 
 
<p>There are quite a few jobs going on today....so to keep track of things I am making a note here:</p> 
 
 
<ul> 
<li>RX Swap:  Sasha & Ignacio did a fibre swap for IB2W0L4 (f204) and found a bit 0 high problem followed the DAQ channel.  So they are swapping an RX to fix the problem.</li> 
<li>SB4W0 CAEN PS Swap:  This morning, I noticed SB4W8L0:DVDD was pink.  I looked at the history and it was rather irratic.  Ignacio looked further and saw the voltage has been drooping and the current shot up at the same time.  Jen and Mark Matthis are now in the collision hall swapping in a new CAEN PS.  However due to lack of good spares, we are putting in the CAEN PS which always gave DOIM PINKS which would go after a second hockerisation.</li> 
<li>SVX09 EVB:  Conor is making b0evme26 ready.  That will allow us to use the EVB for SVX09.  But this EVB came from the test stand and was called b0evme04.  So as a kludge, Conor will keep this name for now. We shall start testing this after the RX & PS swap have completed.</li> 
<li>Fibre installation for SVX09:  The fibres to link the GLINK fibres from SVX09 to SVX06/07/08 are being put in by Jamie.</li> 
<li>SVX09 Readiness:  Once the collision hall work is complete, we will try to run COLDSTART with EVB and COSMICs with SVX09.</li> 
<li>Filming in the collision hall: (Media)-Jen(?) is prepared to come into the collision hall to film Ulrich et al doing Fibre swaps, etc for prosperity and future training.</li> 
</ul>
<!-- Author: For the aid of Ankush&#39s memory -->


<!-- Date: Fri Oct 20 10:20:33 2006 -->
<h3>Thoughts on detector readiness for beam</h3> 
 
<p>During this mini-shutdown, we have done quite a bit of work, especially on the DAQ.  So I really want to make sure we are ready for data.  So we really need to shake down the system and really check everythign is OK.</p> 
 
<p>Here is my proposal.  On Saturday evening, all work, including SVX09 work must stop!!!  On Sunday, we should check the detector is fully functioning.  We should power up the whole detector, run Tuula's Bias Checker script.  Then do COLDSTATT initially and then lots and lots of COSMICs.</p> 
 
<p>We should also check SVXDAQ is setup correctly for SVX09 operation if it is included.</p>
<!-- Author: Ankush -->


<!-- Date: Fri Oct 20 12:48:27 2006 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-10125&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-10126  width='300' align='top'></a></td><td>History plot of SB4W8L0 DVDD, showing before and after the power supply swap.</td></tr></table>
<!-- Author: Jen, Mark Mathis, Sasha -->
<!-- Comment: Fri Oct 20 13;09;53 comment by...Jen, Mark Mathis, Sasha, Ankush, Ulrich -->
<h3>Power supply swap for SB4W8</h3>
Ankush noticed this morning that the DVDD current of SB4W8L0 had gone pink; when we looked at the history of this ladder we saw the DVDD current had been erratic and creeping up for several months, and the DVDD voltage had been drooping.  As a preemptive measure, we decided to swap the supply out now.  Unfortunately, we have no good SVX spares.  So I used a supply which we swapped out a year ago; this supply had the feature that when its crate was hockerized, the DOIMs would turn pink (the current would be low).  A second hockerization always brought the DOIM currents back in line.  I could never reproduce this problem so I never turned it in to Prep.<br>
When we started loadbox testing the supply, we noticed two problems immediately: the 5V DOIM voltage was low (5.08V instead of 5.38V) and the DVDD0 voltage was low (4.5V instead of 5.3V). So we took the supply back upstairs and adjusted them to the correct values.<br>
The rest of the swap went smoothly, and everything biased without any problems (although some of the currents will have to be adjusted, they're pink right now).  But the plot above shows we didn't exactly fix the problem; although the DVDD0 voltage is now where it should be, the current is still very erratic.  However the current is now lower than it was before, so even though it's erratic it shouldn't go pink or set off the software trip limit.<br>
The question now is whether the erratic current is a chip problem or a PS problem.  I checked the logfiles from the burn-in test of this supply (done June 15 2006) and found that indeed the DVDD0 voltage was 4.5V and the 5V DOIM voltage was 5.09V.  So these are problems the supply had when it came out of the collision hall.  Either the voltages were wrong when the supply was first put into the collision hall, or they started "drooping" while the supply was in the hall.  We may have just swapped in a supply with the same problems as the supply we swapped out.<br>
In any case, this is a slow-developing problem.  Since we have no SVX spares, we're leaving this supply in for now.  We'll have to observe the current/voltage behavior on DVDD0 and the 5V DOIM over time.<br>

<!-- Comment: Fri Oct 20 17;00;59 comment by...Ankush -->
<h3>A small oversight in the access report: Jenny-Cam</h3

<p>While the CAEN PS work was going on <em>Media</em>-Jen was filming <em>PS-</em>Jen for prosperity and training. The reviews of Jen's performance were very favourable.  So we may loose our <em>CAEN</em>-Jen to Hollywood....or if she can lip-sync and dance well, she can go to Bollywood.</p>


<!-- Date: Fri Oct 20 13:13:24 2006 -->
Entered in Silicon database: <ul>
<li>Ladder: SB4W8L0 
<li>problem n: 1777 
<li>Status: needs_observation
<li>Type: DVDD
<li>Action: PS_work
<li>entered by: jpursley 
<li>description is: This ladder developed a droopy DVDD voltage and high, erratic DVDD current.  These problems have always been associated with the power supply in the past, so we swapped out the supply.  Unfortunately we have no good spare supplies, so we swapped in one which <i>may</i> have the same problem, also on DVDD0.  Need to observe the current/voltage behavior of DVDD0 over time, see if the voltage starts drooping again.  See <a href= 'http://www-cdfonline.fnal.gov/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=323&frame=2&anchor=12:48:27'>elog</a>. 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B4W8&layer=L0">report</a></ul>
<!-- Author: Problem DB -->



<!-- Date: Fri Oct 20 14:10:50 2006 -->
<h3>Report on access to fix f204</h3> 
 
<p>It was found during last week's detector check-out that f204 was giving 00_sequence errors. This problem was confirmed during quiet time studies earlier this week. It was also traced to back to a problem with bit0 being high. Today, we did a fiber swap for f204 and found that the problem was with DAQ channel. So, we did an RX swap. RX swap didn't fix the problem, so we swapped the FIB. It turns out that FIB also didn't solve the problem either (old FIB was put back in at the end). Because it's bit0 high problem (can be corrected off-line) we decided to give up at this moment. If another opportunity for an access arises, we need to do an FTM swap to finally close this case.</p>
<!-- Author: Sasha, Ankush, Ignacio -->
<!-- Comment: Fri Oct 20 16;54;55 comment by...Ankush -->
<p>The old FIB was not put back into the collison hall.  FIB 137 was pulled out and FIB 103 was put in its place.</p>


<!-- Date: Fri Oct 20 14:12:55 2006 -->
Entered in Silicon database: <ul>
<li>Ladder: IB2W0L4 
<li>problem n: 1776 
<li>Status: needs_work
<li>Type: Chip_bit_error
<li>Action: Diagnosis_update
<li>entered by: sasha 
<li>description is: We did a fiber swap for f204 and found that the problem was with DAQ channel. So, we did an RX swap. RX swap didn't fix the problem, so we swapped the FIB. It turns out that new FIB didn't solve the problem either (old FIB was put back in at the end). Because it's bit0 high problem (can be corrected off-line) we decided to give up at this moment. If another opportunity for an access arises, we need to do an FTM swap to finally close this case. 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=ISL&wedge=B2W0&layer=L4">report</a></ul>
<!-- Author: Problem DB -->




<!-- Date: Fri Oct 20 17:02:50 2006 -->
Entered in Silicon database: <ul>
<li>Ladder: IB2W0L4 
<li>problem n: 1776 
<li>Status: needs_work
<li>Type: Chip_bit_error
<li>Action: Swap_RX
<li>entered by: amitra 
<li>description is: <p>As part of the effort to track down the Bit 0 high problem, the RX was swapped.  However the problem did not go away.</p><table border=1>
   <tr>
    <td>
     <b>IN:</b>
    </td>
    <td>
     <a href="http://b0sili01.fnal.gov/cgi-bin/rxdb/DBreport.pl?serial=0435">0435</a>
    </td>
   </tr>
   <tr>
    <td>
     <b>OUT:</b>
    </td>
    <td>
     <a href="http://b0sili01.fnal.gov/cgi-bin/rxdb/DBreport.pl?serial=0792">0792</a>
    </td>
   </tr>
  </table> 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=ISL&wedge=B2W0&layer=L4">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Fri Oct 20 17:06:26 2006 -->
Entered in Silicon database: <ul>
<li>Ladder: IB2W0/1All 
<li>problem n: 1778 
<li>Status: needs_observation
<li>Type: Chip_bit_error
<li>Action: Swap_FIB
<li>entered by: amitra 
<li>description is: <p>As part of the effort to track down the Bit 0 for IB2W0L4, the FIB was swapped.  However the Bit 0 problem remained.</p><table border=1>
   <tr>
    <td>
     <b>IN:</b>
    </td>
    <td>
     <a href="http://b0sili01.fnal.gov/cgi-bin/fibdb/DBreport.pl?serial=103">103</a>
    </td>
    <td>
     <a href="http://b0sili01.fnal.gov/cgi-bin/fibdb/DBreport.pl?prep="></a>
    </td>
   </tr>
   <tr>
    <td>
     <b>OUT:</b>
    </td>
    <td>
     <a href="http://b0sili01.fnal.gov/cgi-bin/fibdb/DBreport.pl?serial=137">137</a>
    </td>
    <td>
     <a href="http://b0sili01.fnal.gov/cgi-bin/fibdb/DBreport.pl?prep="></a>
    </td>
   </tr>
  </table> 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=ISL&wedge=B2W0/1&layer=All">report</a></ul>
<!-- Author: Problem DB -->



<!-- Date: Fri Oct 20 17:14:16 2006 -->
<h3>Access Report: Labeling of Power Supply Cables</h3> 
In the last couple of month we found two swapped bias cables in ISL supplies. The cables (bias, LV, remote sensor) are not really well-labeled. So we prepared labels for all cables. After all important work was done this morning and we had convinced the ops manager that he wants to stick to his original plan of closing the hall by 15:00 (not already at 14:00), we started that work. We have about 1/3 of the system labeled now: 
<ul> 
<li>NW Bot Bot: done</li> 
<li>NW Bot Top: started (sense and bias cables for IB2W2 and IB0W4 are labeled)</li> 
<li>NW Top Top: done except for slots 7-9</li> 
<li>NE Bot Bot: done (at least I didn't find leftovers)</li> 
<li>NE Bot Top: done (no leftovers either) 
<li>SW Bot Bot: done</li> 
<li>SW Bot Top: done</li> 
<li>SE Top Bot: started (1 label in place, IB4W4 sensor!)</li> 
</ul> 
 So we will have to make use of another opportunity to finish the job. 
<p> 
When we came back up we realized that we had tripped three wedges on external trip during the exercise. SB0W9, SB1W11, and SB2W10. So unfortunately, we had to keep the keys 1/2 hours longer than expected to fix those. Now everything is back up fine.
<!-- Author: Jose, Ricardo, Ignacio, Jen, Mark M., Ankush, Jeannine, Ulrich -->
<!-- Comment: Sat Oct 21 09;05;39 comment by...Jen -->
Yes, NE Bot Bot and NE Bot Top are done.  Also NE Top Bot is started (slots 7-9 done) and NE Top Top is started (slots 5-9 done).
<!-- Date: Fri Oct 20 17:34:55 2006 -->
After all the work was done, we biased the silicon and ran Tuula's bias checker script. Except for these three ladders with know bias issues 
<pre> 
L00	B1W0	3	VBIAS	2.00	Problem DB	0.00 
ISL	B2W2	3	VBIAS1	0.00	Problem DB	0.00 
ISL	B4W1	1	VBIAS1	2.00	Problem DB	0.00 
</pre> 
everything was fine.
<!-- Author: Ulrich -->


<!-- Date: Fri Oct 20 17:36:46 2006 -->
<center><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-10127&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-10128' ></a><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-10129&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-10129' width='300'></a><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-10130&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-10130' width='300'></a></center>
<!-- Author: Ankush -->
<!-- Comment: Fri Oct 20 17;42;06 comment by...Ankush -->
<h3>Fibres from SVX06/07/08 to SVX09</h3>

<p>In the morning, Jamie installed the fibres from SVX09 to SVX06/07/08 to allow us to jumper the GLINK fibres from the collision hall to SVX09.  So the infrastructure is in place...<em>Woo-Hoo!!!</em></p>

<p>For the record, the labels for the fibres and where they go are as follows:</p>

<p>
The fibres going from SVX09 (1RR18C) to SVX06/07(1RR21I) are:
Jumper 00, Jumper 01, Jumper 02 ,Jumper 03, Jumper 04, Jumper 05, Jumper 06, Jumper 07 </p>

<p>The fibres from SVX09 (1RR18C) to SVX08 (1RR18I) are:
Jumper 08, Jumper 09, Jumper 10, Jumper 11, Jumper 12, Jumper 13</p>

<p>I'll update the TWiki page to reflect this.</p>

<!-- Date: Fri Oct 20 18:09:30 2006 -->
Entered in Silicon database: <ul>
<li>Ladder: SB4W8L3 
<li>problem n: 1779 
<li>Status: fixed
<li>Type: AVDD
<li>Action: IMON_limits
<li>entered by: ignacio 
<li>description is: AVDD is slighly lower after changing the power supply. Change IMON limit.<table border=1>
<tr><th>IMON LIMITS</th><th>Old</th><th>New</th></tr>
<tr><td><b>Nominal</b></td><td>792.209</td><td>775</td></tr>
<tr><td><b>Lower</b></td><td>785</td><td>768</td></tr>
<tr><td><b>Upper</b></td><td>800</td><td>783</td></tr></table> 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B4W8&layer=L3">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Fri Oct 20 18:14:10 2006 -->
Entered in Silicon database: <ul>
<li>Ladder: SB4W8L4 
<li>problem n: 1780 
<li>Status: fixed
<li>Type: AVDD
<li>Action: IMON_limits
<li>entered by: ignacio 
<li>description is: AVDD current decreased after the power supply was swapped. Change IMON limits accordinly.<table border=1>
<tr><th>IMON LIMITS</th><th>Old</th><th>New</th></tr>
<tr><td><b>Nominal</b></td><td>1097</td><td>995</td></tr>
<tr><td><b>Lower</b></td><td>1065</td><td>963</td></tr>
<tr><td><b>Upper</b></td><td>1105</td><td>1003</td></tr></table> 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B4W8&layer=L4">report</a></ul>
<!-- Author: Problem DB -->



<!-- Date: Fri Oct 20 19:02:42 2006 -->
<h3>Progress with b0svx09</h3> 
We continued work on b0svx09 today.  First we verified the functionality of all the VRBs we are planning on using.  One of them was not recognized on the VME bus, so we replaced it.  We were then able to run events in svxdaq with the VRB/VTM combos for slots 8, 10, 12, 18 and 20 without problems.  Next I connected the fibers coming from b0fib07 slot 12 (f22) to the VRB in slot 20 of b0svx09 (they were previously connected to b0svx08 slot 20) and updated the hdwdb to reflect this.   With this change we now have two VRBs in b0svx09 which are connected to FIBs, since we had previously connected the fibers from fa4/5 to the VRB in slot 10. Next we ran Coldstart including b0svx09 and did not see any errors in 5000 events.  With Conor's help we then ran Coldstart, but with the HEVB reading out the VRB crates, and this worked as well.  Finally, we included the silicon crates in a cosmics run, which was successful after we loaded the new hdwdb settings.  The plan is to run the silicon in this evening's cosmics run and see if there are any problems. 
<!-- Author: Jose, Ignacio, Ankush, Ulrich, Mark -->



<!-- Date: Sat Oct 21 20:59:07 2006 -->
<h3>b0svx09 in Balanced Configuration</h3> 
This afternoon we installed the fibers to implement the load balancing including b0svx09 as outlined on <a href="http://b0sili01.fnal.gov/cgi-bin/TWiki/bin/view/Silicon/FourCrates6VRB">this Wiki page</a>.  We carried out the following steps to get things working:   
<ol> 
<li>We ran extension fibers from b0svx06/07/08 to b0svx09 for the 6 FIBs that were formerly connected to b0svx06/07/08 but are now connected to b0svx09.   
<li>We disconnected the fibers from the VRBs in b0svx06/07/08 that are not used in the balanced scenario, and connected the fibers to the new VRBs in b0svx09 
<li>We updated the hdwdb to set the unused VRBs in b0svx06/07/08 offline and the new VRBs in b0svx09 online.  We also updated the VRB fields in the FIB card entries.  
<li>We next attempted to run Coldstart, but we ran into a recurrent Busy TO error at ~400 events which was caused by the unused VRBs in b0svx06/07/08.  We removed the unused VRBs in b0svx07/08, but not b0svx06 because we did not want to powercycle the SRC.  After many futile attempts to get the unused VRBs in b0svx06 to behave, we called Marcel and he suggested disabling the J3 connection for the unused VRBs from svxdaq.  This fixed the problem and we should make sure we check the J3 status for VRBs that we are taking offline or online in the future. 
<li>After running successfully in Coldstart we called up Conor and had him set up the HEVB to read out the new VRBs in b0svx09.  We then ran Coldstart using the HEVB to read out events but ran into L3 reformatter errors because f104 and f44/5 where missing from some events.  By then Conor had come in and we had discovered that a few of the fibers may not have been connected well. 
<li>Having fixed the fiber connections and confirmed that f44/5 and f104 were reading out in svxdaq, we included the silicon in a cosmics run.  This was successful and there are no unexpected yellows in SVXMon. 
</ol> 
The plan is to include the silicon in an overnight cosmics run tonight and see how it does.  If we have time before the Tevatron is back, we should also try a sparky run with a pumped up L2 rate.  We will ask ops to make sure that we are informed before the first data taking store next week, so we can roll back to the old VRB configuration if necessary.
<!-- Author: Ankush, Ignacio, Jose, Ulrich, Mark -->
<!-- Comment: Sun Oct 22 08;33;53 comment by...Ulrich -->
Seems that the overnight cosmics runs was successful. At least there was nothing mentioned in the e-log. 


<!-- Date: Sun Oct 22 13:38:31 2006 -->
<pre>I called in around 1:00 becasue the alphanumeric was going mad. Tevatron  has rebooted the machine that gives us the clock. Whole SVX and L00 has tripped. I asked the aces to page Ankush and drove in. 
  
</pre>
<!-- Author: Ignacio -->
<!-- Comment: Sun Oct 22 14;20;40 comment by...Ignacio -->
<pre>Detector was put back on standby after Steve Hahn called. 
We wil run cosmiscs to check everything is allright.
</pre>


<!-- Comment: Sun Oct 22 14;58;11 comment by...Marcel -->
I thought at some point we had an agreement with MCR to tell us before they do reboot the LLRF. Maybe we need to remind them again in a nice or not so nice way to really tell us in advance if they are going to do this.
<!-- Comment: Sun Oct 22 15;25;09 comment by...Ulrich -->
Reading the main e-log it seems also that our shift crew had now clue what LLRF is, left alone that it has something to do with our clock. It may well be that they called and nobody understood the implications... Here's the main e-log:
<pre>
MCR made some cryptic commend about "rebooting the tevatron" to our SicCo that  might be related.
She is calling back for more information. MCR elog says The Tevatron is HEP-ramping. Will continue
investigating. 
 - Ford :: (run 225995)
-- Sun Oct 22 13:10:42 comment by...Ford --  
MCR says they rebooted the computer that sends the 53 MHz beam sync signal. I would guess this
caused the stay alive signal to stop being sent to our silicon.
</pre>
The MCR e-log sound like they rebooted the LLRF first and then called the experiments:
<pre>
13:28:14-  Tev RF is not putting out any gap envelope. John Reid is looking into it. - m.m
-- Sun Oct 22 13:49:50 comment by...m.m --  Before calling John i rebooted the Tev LLRF, and called the experiments.
</pre>
So we should really have a word with MCR.
<!-- Date: Sun Oct 22 14:22:19 2006 -->
<center><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-10131&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-10132' ></a><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-10133&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-10134' ></a></center>
<!-- Author: Ignacio -->
<!-- Comment: Sun Oct 22 14;24;24 comment by...Ignacio -->
So that is how it looked for the record. Most of SVX tripped and a couple of wedges of L00. ISL remained quite happy appart for DVD going pink.

<!-- Date: Sun Oct 22 14:52:50 2006 -->
Entered in Silicon database: <ul>
<li>Ladder: SB4W8All 
<li>problem n: 1781 
<li>Status: needs_observation
<li>Type: VDOIM
<li>Action: IMON_limits
<li>entered by: ignacio 
<li>description is: Increase limit by a bit after swapping PS.<table border=1>
<tr><th>IMON LIMITS</th><th>Old</th><th>New</th></tr>
<tr><td><b>Nominal</b></td><td>1932.55</td><td>1990</td></tr>
<tr><td><b>Lower</b></td><td>1925.0</td><td>1985</td></tr>
<tr><td><b>Upper</b></td><td>1950.0</td><td>2010</td></tr></table> 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B4W8&layer=All">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Sun Oct 22 14:56:28 2006 -->
Entered in Silicon database: <ul>
<li>Ladder: SB4W8All 
<li>problem n: 1781 
<li>Status: needs_observation
<li>Type: VDOIM
<li>Action: IMON_limits
<li>entered by: ignacio 
<li>description is: As the above entry (that correspond to the 5 V) but for the 2V.<table border=1>
<tr><th>IMON LIMITS</th><th>Old</th><th>New</th></tr>
<tr><td><b>Nominal</b></td><td>1114.5</td><td>1170</td></tr>
<tr><td><b>Lower</b></td><td>1105</td><td>1160</td></tr>
<tr><td><b>Upper</b></td><td>1130</td><td>1185</td></tr></table> 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B4W8&layer=All">report</a></ul>
<!-- Author: Problem DB -->




<!-- Date: Sun Oct 22 14:59:54 2006 -->
We hockerized crate 13 before changing limits  because this power supply has a history of requiring a extra hockerization to  
produce the correct voltage. In this case nothing changed.
<!-- Author: Ankush/Jose/Ignacio -->


<!-- Date: Sun Oct 22 15:06:01 2006 -->
<h3>Low Level RF rebooted</h3> 
 
<p>Ignacio called in after the alphanumeric went crazy.  The whole detector had tripped off.  It turns out the Low Level RF was rebooted.  According to the SciCo, the MCR called up <em>after</em> the RF was rebooted to tell us they just did it.  No surprise that as soon as they called the detector started tripping.</p> 
 
<p>So it would appear the MCR are the bad boys this time as they should have informed us <em>before</em> they rebooted the RF.  This is not the first time this has happened. </p> 
 
<p>Of course we do have a detterent against this: the CCC.  But as the wise man I am, I took this card out.  Hmmmm...should we put it back in ?</p> 
 
  
<!-- Author: Ankush, Ignacio and Jose -->
<!-- Comment: Sun Oct 22 16;12;43 comment by...Ankush -->
<h4>...a few more details....</h4>

<p>I forgot a couple of things</p>

<p>Ignacio brought the detector back up with no problems.  We did a COLDSTART and went to activate with no problems.  As there was no beam, we did a quick Silicon COSMICs and the detector readout was fine.  So it appears we did not suffer from this.</p>

<p>Along the way, Ignacio adjusted the IMON DOIM limits for SB4W8; the power supply we swapped on Friday. The DOIM lines were PINK and this power supply has a history of going PINK on the DOIM which are cleared by a Hockerisation.  However afer hockerising the CAEN the DOIM currents went back to the same value.  Also a closer look showed the new values were just above the old limits.  So that's why we bumped up the limits for now.</p>

<p>As for the incident itself....hmmmm....a LOTO on the LL RF ?</p>


<!-- Date: Mon Oct 23 09:23:00 2006 -->
<h3> Week Summary</h3> 
 
<p>No beam this week but a lot of access work. b0svx09 is born. 
 </p> 
<p> Monday: 
<li>Cooling down/powering up  the detector after bore  access last week. Silicon standby around 14:00. Cosmic run data look OK.  Micron sensors remain pink while discharging themselves.</li> 
<li>Quite time studies.</li> 
</p> 
<p> Tuesday: 
<li> All 4 racks in collision hall turned off At 4:00 AM becasue  of faulty quadlog temperature sensor. </li> 
<li> Ulrich & Cryo  
exchange the sensor by  
<a href='http://www-cdfonline.fnal.gov/cgi/internal/elog/det-system-elog.pl?nb=silicon&action=copyentry&page=323&time=17:49:19'> 
cooling surgery</a> (sensor was within cooling line) over the day. After surgery rate of rise test on that line reveals that it is even tigher than before.</li> 
<li> Bias detector (OK) and request cosmics overnight (OK)to check everything allright.</li> 
<li> Event size scan provided by L2 people (<a href= 
'http://www-cdfonline.fnal.gov/cgi/internal/elog/det-system-elog.pl?nb=silicon&action=copyentry&page=323&time=22:13:45'> 
plot</a>). At 1 KHZ L2A rate wall is at 25 kbytes/EVBCPU. 
</li> 
<li> Testing VTMs to include in b0svx09</li> 
</p> 
Wendsday: 
<li> 
<a href='http://b0sili01.fnal.gov/cgi-bin/TWiki/bin/view/Silicon/NewSiliconCrate'> B0svx09 twiki</a>. </li> 
</p> 
 
<p>Thursday: 
<li>Quite time studies and  
<a href='http://www-cdfonline.fnal.gov/cgi/internal/elog/det-system-elog.pl?nb=silicon&action=copyentry&page=323&time=13:26:30'> access</a>. b0fib07 reseated.</li> 
</p> 
<p> Friday:  
<a href='http://www-cdfonline.fnal.gov/cgi/internal/elog/det-system-elog.pl?nb=silicon&action=copyentry&page=323&time=10:12:09'> 
Full scale attack</a>.  
<li> <a href='http://www-cdfonline.fnal.gov/cgi/internal/elog/det-system-elog.pl?nb=silicon&action=copyentry&page=323&time=12:48:27'> 
Replace</a> PS powering SB4W8 by "good" spare PS. "Good" meaning that it failed in the collision hall before but works fine in the teststand. So far no porblems appart for minor changes in currents reported by IMON.</li> 
<li> Seal  
<a href='http://www-cdfonline.fnal.gov/cgi/internal/elog/det-system-elog.pl?nb=silicon&action=copyentry&page=323&time=09:56:18 
'>leak</a> 
 reported by Dervin on "West ISL manifold, at the Portcard branch"</li> 
<li>Regular detector maintenance continues from yesterday.</li> 
<li> 
Power supply labeling effort (8 people in collision hall). More than half  
<a 
href='http://www-cdfonline.fnal.gov/cgi/internal/elog/det-system-elog.pl?nb=silicon&action=copyentry&page=323&time=17:14:16'> 
done<a>.  
</li> 
</p> 
<p> 
Saturday: 
<li> 
b0svx09 finally in <a href=' 
http://www-cdfonline.fnal.gov/cgi/internal/elog/det-system-elog.pl?nb=silicon&action=copyentry&page=323&time=20:59:07'> 
balance configuration</a>(which is present status). Able to run from RC after Connor gives the final EVB touch. Run overnight cosmics allright. 
</li> 
</p> 
<p> 
Sunday: 
<li> 
MCR rebooted Low Level RF machine, apparently told CDF afterwards. Clock lost,  
<a href='http://www-cdfonline.fnal.gov/cgi/internal/elog/det-system-elog.pl?nb=silicon&action=copyentry&page=323&time=14:22:19'> 
SVX trips</a>. Detector recovered without problems. 
  
</li> 
</p>
<!-- Author: Ignacio -->