<!-- Title: 10:08:02  Mon Dec  5 2005 -->
<!-- Crewchief: Oscar -->
<!-- Op1: Ankush -->
<!-- Op2: &nbsp; -->
<!-- Op3: &nbsp; -->
<!-- Op4: &nbsp; -->
<!-- Op5: &nbsp; -->
<!-- Op6: &nbsp; -->
<!-- Notes: -->
<pre>My first week... we started well switching everything on and it almost work (a L00 ladder didn't join the party :)</pre>


<!-- Date: Mon Dec 5 11:09:25 2005 -->
<table border=0><td><tr><td bgcolor=#e0e030><h3>Silicon Back On</h3> 
 
<p>5V ENABLES are active</p> 
<p>PS-GUI CAEN Alarsm in IFIX have been re-enabled</p> 
<p>Silicon now on STANDBY</p></td></tr></td></table>
<!-- Author: Ankush & Oscar -->


<!-- Date: Mon Dec 5 11:47:14 2005 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7968&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7968  width='300' align='top'></a></td><td>Temp and humidity in the coll hall</td></tr></table>
<!-- Author: Sebastian -->
<!-- Comment: Mon Dec  5 11;58;22 comment by...Jen/Sebastian -->
We went in to check fa33 which keeps tripping on DVDD and VBIAS undervoltage. We went to the coll hall to take a look but the SE archer was openned and there is no way to get to the PS (SE TopBot). We did notice that it was very humid down there. The plot
above shows that there was an increase in humidity this morning. The question is if the trips of fa33 are related to this. May be not, because we first tried turning the ladder to STBY around 9am and it was tripping the same way.


<!-- Comment: Mon Dec  5 19;06;25 comment by...sebastian -->
It is still tripping in the evening, tomorrow we should try to swap PS cables...
<!-- Date: Mon Dec 5 14:32:12 2005 -->
<table><tr><td><a href=/elog/notebooks/silicon/Mon_Dec__5_2005_143204.ps align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7970  align='top'></a></td><td>SVX Daq plots for SB0W11L2(e0b2) taken in next-neighbor mode. Chip 86 & 85 (channels 384-512) they have low noise and dnoise.</td></tr></table>
<!-- Author: Oscar/Ankush -->


<!-- Date: Mon Dec 5 16:28:00 2005 -->
<table border=0><td><tr><td bgcolor=#e0e030><h3>Unsilenced cooling alarms!!!</h3> 
 
<p>I just noticed the cooling sono-alarms were still silenced from Friday.</p> 
 
<b>NB: Remember to unsilence the sono-alarms after the cooling has been recovered!!!!!</b><</td></tr></td></table>
<!-- Author: Ankush -->

<!-- Date: Mon Dec 5 17:45:52 2005 -->
Entered in Silicon database: <ul>
<li>Ladder: SB3W10L4 
<li>problem n: 1500 
<li>Status: needs_work
<li>Type: DVDD
<li>Action: PS_work
<li>entered by: amitra 
<li>description is: <p>After bringing the detector back up I tried to power this ladder.  Unfortunatly it is still tripping on DVDD overcurrent.</p> 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B3W10&layer=L4">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Mon Dec 5 17:48:48 2005 -->
Entered in Silicon database: <ul>
<li>Ladder: SB0W11L2 
<li>problem n: 1573 
<li>Status: needs_observation
<li>Type: Chip_bit_error
<li>Action: Incident
<li>entered by: amitra 
<li>description is: <p>This ladder now gives no errors in RA or NN mode after 10,000 events.  In NN mode, I did notice chips 86 and 85 has very low noise and dnoise.  See <a href= 'http://www-cdfonline.fnal.gov/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=278&frame=2&anchor=14:32:12'> here</a> for SVXDAQ plots posted in silicon e-log.</p>    
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B0W11&layer=L2">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Mon Dec 5 17:51:06 2005 -->
Entered in Silicon database: <ul>
<li>Ladder: SB0W2L2 
<li>problem n: 1574 
<li>Status: needs_work
<li>Type: Chip_bit_error
<li>Action: Incident
<li>entered by: amitra 
<li>description is: <p>This ladder gives always gives c2c2 for the first few entries and then runs error free.  This occurs in NN and RA mode. The next step is to check the SVXDAQ and online HW DB settings are the same.</p> 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B0W2&layer=L2">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Mon Dec 5 17:54:55 2005 -->
Entered in Silicon database: <ul>
<li>Ladder: SB0W6L3 
<li>problem n: 1576 
<li>Status: fixed
<li>Type: Chip_bit_error
<li>Action: Incident
<li>entered by: amitra 
<li>description is: <p>I noticed the SVXDAQ and online HW DB settings were not the same.  After making SVXDAQ have the same settings as the online HW DB this ladder ran error-free in RA & NN mode after 10,000 events.</p> 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B0W6&layer=L3">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Mon Dec 5 17:56:06 2005 -->
Entered in Silicon database: <ul>
<li>Ladder: SB3W0L1 
<li>problem n: 1577 
<li>Status: fixed
<li>Type: Unknown
<li>Action: Incident
<li>entered by: amitra 
<li>description is: <p>I noticed SVXDAQ and the online HW DB settings were not the same.  After settting SVXDAQ to the online HWDB settings, this ladder runs error-free in NN and RA mode after 10,000 events.</p> 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B3W0&layer=L1">report</a></ul>
<!-- Author: Problem DB -->



<!-- Date: Mon Dec 5 17:57:02 2005 -->
With the help of Bill B and Ricardo I moved the <b>imon</b> package onto the new fileserver, put imon into cvs (it was not there...) and compiles and runs fine.
<!-- Author: Sebastian -->

<!-- Date: Mon Dec 5 18:01:33 2005 -->
Entered in Silicon database: <ul>
<li>Ladder: SB0W11L3 
<li>problem n: 1579 
<li>Status: needs_work
<li>Type: Chip_capid
<li>Action: Incident
<li>entered by: amitra 
<li>description is: <p>The detector had been off for ~7 days. After powering up and in investigating SB0W11L2 (e0b2) I noticed this ladder was giving CAP-ID errors.  Need to check the SVXDAQ and online HW DB settings are the same and see if this problems is a pre-existing one.</p> 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B0W11&layer=L3">report</a></ul>
<!-- Author: Problem DB -->



<!-- Date: Mon Dec 5 18:42:00 2005 -->
<h4>Re-re-examination of SVX ladders from the mega-quench & powering on the detector after 7 days OFF</h4> 
 
<p>It has been 7 days (counting inclusively) since the detector was powered OFF.  This was due to all the eletrical work taking place in the counting room.  During this whole period, the detector has had cooling; except for a  ~30 min gap for B0 eletrical work.  For this period SVX was set to -6C (to keep the COT happy) while ISL remained at +6C.</p> 
 
<p>In the morning we powered up the detector again and most ladders came back.  But of course we have had some unexpected events....</p> 
 
<ul> 
<li>LB1W3L3 (fa33) : This cannot be powered on.  It keeps tripping on VBias undervoltage.</li> 
<li>PINKIES in SB0W1L2 (e012) & SB5W0L2 (e502)</li> 
<li>Some further PINKIES in two DOIMs but were fixed by hockerising crates 13 & 14.</li> 
<li>SB3W10L4 (e3a4) : This was tripping before switching the detector off.  But even after the rest it is still refusing to switch on.  It is still tripping on DVDD overcurrent.</li> 
</ul> 
 
<p>At the moment we have not investigated LB1W3L3 (fa33).  This ladder lives in SE-top-bottom and both the South Wall and SE arch are out due to XFT work.  So it is impossible to get to the crate. We have asked the XFT people to complete their work at SE ASAP so we can retract the arch.</p> 
 
<p>SB3W10L4 (e3a4) is starting to look like a hopeless case.  It has been given plenty of time off and it still refuses to come back.  The worry is this wedge already has SB3W10L3 (e3a3) out.  So this will crete an SVT hole.  However Marcel suggests asking Roberto to see if SVT can work with Layers 0,1,2 for this wedge.</p> 
 
<p>After the post mega quench detector checkout, 4 SVX ladders were giving suspicious data.  I re-examined those ladders with the results below:</p> 
 
<ul> 
<li>SB0W11L2 (e0b2): This was giving errors but is now running error-free in SVXDAQ  in NN and RA mode after 10,000 events.  However in NN mode, the noise & dnoise look very small for chips 86 & 85. (see  
<a href= 
'http://www-cdfonline.fnal.gov/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=278&frame=2&anchor=14:32:12'> 
here</a>)</li> 
<li>SB0W11L3 (e0b3): This ladder was found to be now giving CAP-ID errors in SVXDAQ.  But this may be a pre-exisiting condition.</li> 
<li>SB0W2L2 (e022): This ladder was always giving c2c2 for the first few events and then ran error-free.  This ladder continues to give the same problem.  Needs further investigation.</li> 
<li>SB0W6L3 (e063) & SB3W0L1 (e301): Both ladders were found to be giving errors during the initial checkout.  However the SVXDAQ chip settings did not match the online HW DB settinngs.  Once the SVXDAq settings matched the online HW DB settings, both ladders ran error-free in RA & NN mode for 10,000 events.</li> 
</ul>  
<!-- Author: Ankush & Oscar -->
<!-- Comment: Mon Dec  5 18;59;54 comment by...Ankush -->
<h4>Mass hockerisation</h4>

<p>As LB1W3L3 was refusing to turn on and SB0W1L2 + SB5W0L2 were giving PINKIES in AVDD, I decided to try a mass hockerisation.  So I hockerised crates 1,9 an 12.  This fixed the PINKIES.  But LB1W3L3 is still refusing to come back.</p>



<!-- Comment: Mon Dec  5 19;09;42 comment by...Ankush -->
<h4>Taken LB1W3L3 out of HWDB</h4>

<p>I have taken LB1W3L3 out of the hardware database for the time being.  This should avoid any unnecessary pages during the night.</p>

<!-- Comment: Mon Dec  5 19;17;17 comment by...Ankush -->
<h4>COLDSTART</h4>

<p>Now I have taken LB1W3L3 out of the HWDB I did a COLD START and ran for 5000 events. No errors seen. However I haven't fixed the pinkie for SB5W0L2.  It keep coming and going.  I will put it to IGNORE for the time being.  Hopefully this will go back to normal once we return SVX to -10C.</p>
<!-- Comment: Mon Dec  5 19;42;50 comment by...Ankush -->
<h4>Cooling warnings in SVX & L00</h4>

<p>Just looked at the IFix alarms summary page and noticed some cooling warnings</p>

<ul>
<li>SVX: Bulkhead East #2 (TE-BHE2-5) is now at -0.78C.  The alarm limit is at +1.0C.  However I don't believe this is a problem as the temperature was upto +0.98C last week.</li>
<li>L00: Silicon #4 West outlet (TE-CCWL00-3) temperature is at -0.9C.  The alarm is at 0.0C.  I haven't checked it with a reading from last week as I can't find the temperature in the IFix cooling history page.</li>
</ul>
<!-- Comment: Mon Dec  5 20;08;31 comment by...Ankush -->
<pre>OK...Rainer just showed me how to use the web temperature plotter.  TE-CCWL00-w was at -0.9C last week. So everything is cool</pre>
<!-- Date: Mon Dec 5 19:12:52 2005 -->
Entered in Silicon database: <ul>
<li>Ladder: LB1W3L3 
<li>problem n: 1580 
<li>Status: needs_work
<li>Type: BIAS
<li>Action: Removed_hdwdb
<li>entered by: amitra 
<li>description is: <p>The detector was OFF for 7 days.  After turing back to STANDBY, this ladder is constantly tripping on VBias1 under voltage.  For time being, I have taken this ladder out of the Hardware database.</p> 
<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: Tue Dec 6 09:19:17 2005 -->
<h4>b0dap33 / RTServer dead</h4> 
 
<p>Due to the electical work on the third floor b0dap33 which hosts the RTServer is not working.  The PC was put on UPS but that didn't work.  So for the time being IMON and PS-Gui are not functioning....</p> 
 
<p>The current estiamtes are the work will be done by mid-day....</p>
<!-- Author: Ankush -->

<!-- Date: Tue Dec 6 09:52:25 2005 -->
Entered in Silicon database: <ul>
<li>Ladder: SB0W11L3 
<li>problem n: 1361 
<li>Status: fixed
<li>Type: Chip_capid
<li>Action: Diagnosis_update
<li>entered by: oscar 
<li>description is: <pre>Checked with bit-reported. Seems to be fine and not reporting errors.</pre> 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B0W11&layer=L3">report</a></ul>
<!-- Author: Problem DB -->



<!-- Date: Tue Dec 6 10:55:25 2005 -->
<h3>RTServer move</h3> 
 
<p>So while b0dap30 was off, Bill has moved the RTServer to b0server01 which now the new home for the RTServer.  Bill modified the svxinter startup script.</p> 
<!-- Author: Ankush -->
<!-- Comment: Tue Dec  6 10;55;57 comment by...Ankush -->
<pre>As a consequence of this move, PS-Gui and IMON are now working again :-)</pre>


<!-- Date: Tue Dec 6 11:00:55 2005 -->
<pre>For future reference, the current SVXINTER start up script is: 
 
/cdf/code-common/cdfonline/caencontrol/v3_3_b/examples/startup_rtlm 
 
The new new lines added by Bill are: 
 
# Mount File Systems 
# unnecessary...so I removed them SCN 
hostAdd "b0dau30", "131.225.236.1" 
hostAdd "b0dap33", "131.225.236.33" 
hostAdd "b0dap78", "131.225.236.228" 
hostAdd "b0dap73", "131.225.236.223" 
hostAdd "b0dap57", "131.225.236.167" 
hostAdd "b0server01", "131.225.236.173"  <--- This is new !! 
#hostAdd "b0dau31", "131.225.236.3" 
#hostAdd "b0dau00", "131.225.236.56" 
#nfsMount "b0dau30", "/cdf/code-common/cdfonline/cdfvme_common/v1_0/server", "/commonLib" 
#nfsMount "b0dau30", "/cdf/code-common/cdfonline/robin", "/robinLib" 
</pre>
<!-- Author: Ankush -->
<!-- Comment: Tue Dec  6 11;09;54 comment by...sebastian -->
Restarted the spy processes in b0dasvx03, looks fine.


<!-- Date: Tue Dec 6 11:55:28 2005 -->
<br> 
We rebooted all the b0svx crates (the fibs were done by Bill) and the connections to the new rtserver worked ok. One minor issue is that the serial line to b0svx03 seems to have problems, it does not work, but when we changed the ports on b0dap10 it did work (swapping b0svx02(123) with 03(125), only on the b0dap10 side). We will mail Jonathan about this.
<!-- Author: Ankush/Sebastian -->


<!-- Date: Tue Dec 6 14:07:14 2005 -->
<h4>Restarted Temperature, CAEN processes on SVXICON</h4> 
 
<p>As the RT-Server had moved from b0dap33 to b0server01, the temperature, CAEN info published by SVXICON had to be restarted.  They pciked the change of the RT Server location and seem to be running fine now.</p>
<!-- Author: Ankush & Marcel -->

<!-- Date: Tue Dec 6 19:46:29 2005 -->
Entered in Silicon database: <ul>
<li>Ladder: LB1W3L3 
<li>problem n: 1580 
<li>Status: needs_observation
<li>Type: AVDD
<li>Action: IMON_limits
<li>entered by: amitra 
<li>description is: <p>After successful power-supply swap this ladder is now active.  OHowever the AVDD had to be changed.</p><table border=1>
<tr><th>IMON LIMITS</th><th>Old</th><th>New</th></tr>
<tr><td><b>Nominal</b></td><td>262.5</td><td>270.0</td></tr>
<tr><td><b>Lower</b></td><td>260.0</td><td>265.0</td></tr>
<tr><td><b>Upper</b></td><td>265.0</td><td>275.0</td></tr></table> 
<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: Tue Dec 6 19:50:37 2005 -->
Entered in Silicon database: <ul>
<li>Ladder: LB1W3L0 
<li>problem n: 1581 
<li>Status: needs_observation
<li>Type: AVDD
<li>Action: IMON_limits
<li>entered by: amitra 
<li>description is: <p>After successful power supply swap the AVDD limits had to be changed.</p><table border=1>
<tr><th>IMON LIMITS</th><th>Old</th><th>New</th></tr>
<tr><td><b>Nominal</b></td><td>182.5</td><td>195.0</td></tr>
<tr><td><b>Lower</b></td><td>180.0</td><td>190.0</td></tr>
<tr><td><b>Upper</b></td><td>185.0</td><td>200.0</td></tr></table> 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=L00&wedge=B1W3&layer=L0">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Tue Dec 6 19:51:50 2005 -->
Entered in Silicon database: <ul>
<li>Ladder: LB1W3L1 
<li>problem n: 1582 
<li>Status: needs_observation
<li>Type: AVDD
<li>Action: IMON_limits
<li>entered by: amitra 
<li>description is: <p>After a successful power supply swap the AVDD limits had to be changed.</p><table border=1>
<tr><th>IMON LIMITS</th><th>Old</th><th>New</th></tr>
<tr><td><b>Nominal</b></td><td>172.5</td><td>185.0</td></tr>
<tr><td><b>Lower</b></td><td>170.0</td><td>180.0</td></tr>
<tr><td><b>Upper</b></td><td>175.0</td><td>190.0</td></tr></table> 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=L00&wedge=B1W3&layer=L1">report</a></ul>
<!-- Author: Problem DB -->



<!-- Date: Tue Dec 6 19:53:20 2005 -->
<h3>Power Supply Swap of LB1W3</h3> 
fa33 finally began tripping Undervoltage even when it was turned to standby - the PDB shows this guy has had its voltage steadily decreased b/c of undervoltage trips when trying to bias it.  So we went down today to diagnose it.<br> 
We tried checking and replacing the crowbar, and powercycling the crate.  Neither helped.  So then we tried swapping cables with neighboring supply LB1W2.  With the wedges swapped, the LB1W3 supply could be turned on, but L3 still tripped UnV.  LB1W2 tripped 2V DOIM Overcurrent, so we couldn't power fa33 with it.  But the problem clearly stayed with the power supply, so we decided to swap in our one good L00 spare.<br> 
We swapped the supplies and hooked the new supply up to a L00 loadbox.  It took several iterations of cables, junction cards, loadboxes, with a casualty of one blown crowbar, to get the setup working properly.  Once it was, the supply loadbox tested perfectly.  We cabled it up, biased it, and ran with SVXDaq.  Everything looks good and fa33 is no longer tripping!  And we've learned many valuable lessons for the next time we have to swap a L00 supply...<br>
<!-- Author: Jen, Marcel, Mark, Oscar, Ankush -->
<!-- Comment: Wed Dec  7 09;02;02 comment by...A voice from the underworld -->
<h2>We rock !</h2>
<!-- Date: Tue Dec 6 19:56:41 2005 -->
Entered in Silicon database: <ul>
<li>Ladder: LB1W3All 
<li>problem n: 1583 
<li>Status: needs_observation
<li>Type: VDOIM
<li>Action: IMON_limits
<li>entered by: amitra 
<li>description is: <p>After successful power supply swap the 2V-DOIM IMON limits had to be changed.</p><table border=1>
<tr><th>IMON LIMITS</th><th>Old</th><th>New</th></tr>
<tr><td><b>Nominal</b></td><td>682.549</td><td>650.0</td></tr>
<tr><td><b>Lower</b></td><td>675.0</td><td>625.0</td></tr>
<tr><td><b>Upper</b></td><td>725.0</td><td>675.0</td></tr></table> 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=L00&wedge=B1W3&layer=All">report</a></ul>
<!-- Author: Problem DB -->



<!-- Date: Tue Dec 6 23:22:07 2005 -->
<h3>Setting TE-BHE2-5 and TE-CCWL00-3 to IGNORE</h3> 
 
<p>Last night and tonight, Eva has been paged due to two temperature readings going above their warning limit. This is due to SVX now running at -6C rather than our nominal -10C. To avoid any further false pages, I have set TE-BHE2-5 (SVX) and TE-CCWL00-3 (L00) to INGORE in the iFix Global Alarms Summary page.</p> 
 
<p><b>Once we return SVX to -10C remember to re-enable these alarms!!!</b></p>
<!-- Author: Ankush -->


<!-- Date: Tue Dec 6 23:28:11 2005 -->
<pre>I am going to work on muon3 machine for a while for debugging hvmon program. I will turn off HV power supply of CES, CMP, CMX, and BMU.  If any expert related to this system is going to access detectors in the collision hole, she should contact me first.</pre>
<!-- Author: Yeongdae Shon -->
<!-- Comment: Wed Dec  7 08;23;37 comment by...annoyed -->
<pre>...great...the Silicon E-log is really turning into the Silicon blog....

...we&#39re even getting crappy entries about hvmon, etc.</pre>


<!-- Comment: Wed Dec  7 09;00;46 comment by...Marcel -->
maybe we should drag him in the hall and let him polish the racks, they could definetely use some cleaning ...<br>
Lots of Dust.

<!-- Date: Wed Dec 7 08:52:44 2005 -->
<h3>Work on ISL chiller vacuum pump</h3> 
Warren, KC, and Bill started to debug the problematic vacuum pump ISL VP1-A we discovered <a href= 
'http://www-cdfonline.fnal.gov/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=277&frame=2&anchor=12:16:41'> 
last week</a>. They first followed the chain of relays from the 24 V command issued by iFix to the 120 V relay to actually switch on the pump. The full chain works fine, the pump 
turns on, but it does not create a vacuum. KC will now replace the 
pump. 
<p> 
We had a transient cooling alarm when Bill switched to the broken pump and the air separator pressure went up. However, there was no trip.  
<!-- Author: Ankush & Ulrich -->
<!-- Comment: Wed Dec  7 09;30;09 comment by...Ulrich -->
<br>
Update: KC has replaced VP1-A. Now the system runs on that pump, which brought the air separator pressure down from 2.1 psi using VP2-A to 1.2 psi. KC will also replace VP2-A now. 


<!-- Date: Wed Dec 7 11:15:03 2005 -->
<br> 
Warren, KC, and Bill have also exchanged ISL VP2-A and check if they can switch and if the vacuum is fine. In addition, they checked out the vacuum pumps for the SVX chiller. The system passed all these tests.
<!-- Author: Ulrich -->


<!-- Date: Wed Dec 7 11:27:24 2005 -->
<br> 
<b> CAENcurrents updated in hdwdb </b> 
<br> 
<br> 
After all this time, I finally updated the hardware database to reflect the famous CAENcurrents "gino" file.  Now if one runs the script from traceSilicon or from the cardEditor to create CAENcurrents.dat you will get the correct values.  I did a diff with the "gino" file and appart from white spaces (shouldn't matter but we should check) the files are identical.  Now if one wants to make a change to these settings they should be done from the hdwdb first and then create the file. 
<br>  
<br> 
Additionally, I put the sql script that entered the values in the  directory where I have all the other sql scripts, ~svxii/sql_scripts.
<!-- Author: Eva H. -->
<!-- Comment: Wed Dec  7 16;26;20 comment by...Eva, Ankush -->
<br>
Ankush and I tested the new CAENcurents.dat file generated from the hdwdb.  It was read in successfully but we found that there were two settings that needed to be re-adjusted.  The two guys that tripped on overcurrent were: IB1W1L2 VBIAS1 (changed max current from 500->5000) and IB1W4L0 VBIAS1 (500->5000).  We checked the history of the currents draw for these guys and they historically were drawing higher than 500 so our guess is that they were tweaked by hand at some point and not changed in the "gino" file. 

<br> <br>
We regenerated a new file using the cardEditor and uploaded using the PSGui.  We powered the detector and got no trips.  So we declare success.
<br> <br>
One more thing to note is that if we want to make changes to these settings we cannot use traceSilicon at the moment.  We asked Bill Badgett to add this feature (they are called ISET1 and ISET2 and are in chipchains).  I recall that Bill Badgett wrote traceSilicon but he claims he did not but he said it would be an easy thing to add.  Anyone remember who originally wrote traceSilicon (wasn't me or Bill)?
<br>
<!-- Date: Wed Dec 7 11:48:01 2005 -->
<h3>SVX: on it's way back down to -10 C</h3> 
SVX setpoint was lowered this morning from -6 C to -8 C; once happily at -8, I then lowered it again to the original setpoint of -10. Now, monitor flows and pressures carefully as the temperature lowers slowly this afternoon. 
<p> 
<h3>SVX Bulkhead East #2 Temperature Alarm UNignored</h3> 
TE-BHE2-5 was ignored earlier as the setpoint was at a higher -6C for SVX. Now, comfortably under the 0 degree low alarm limit, it has been set to ignore = NO.
<!-- Author: Jennifer :-) -->


<!-- Date: Wed Dec 7 18:06:08 2005 -->
Entered in Silicon database: <ul>
<li>Ladder: LB1W3All 
<li>problem n: 1583 
<li>Status: needs_observation
<li>Type: VDOIM
<li>Action: IMON_limits
<li>entered by: oscar 
<li>description is: Need to increase the limit on IMon due to PS change.<table border=1>
<tr><th>IMON LIMITS</th><th>Old</th><th>New</th></tr>
<tr><td><b>Nominal</b></td><td>650</td><td>675</td></tr>
<tr><td><b>Lower</b></td><td>625</td><td>625</td></tr>
<tr><td><b>Upper</b></td><td>675</td><td>725</td></tr></table> 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=L00&wedge=B1W3&layer=All">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Wed Dec 7 18:51:38 2005 -->
Entered in Silicon database: <ul>
<li>Ladder: SB5W0L0 
<li>problem n: 647 
<li>Status: needs_observation
<li>Type: Unknown
<li>Action: Monitoring
<li>entered by: sasha 
<li>description is: There was another single incident (run 207405) when this ladder gave trash data (it's not even clear what is the error type) with error rate ~28%. Otherwise, there are no other significant problems. We ran this ladder in RA and NN modes for 10K events--- no problems. I'm passing it back to monitoring group. If the condition doesn't get worse during next two weeks, we can declare it fixed because these events of ladder madness are not systematic. 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B5W0&layer=L0">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Wed Dec 7 18:56:33 2005 -->
Entered in Silicon database: <ul>
<li>Ladder: SB0W2L1 
<li>problem n: 784 
<li>Status: fixed
<li>Type: Chip_bit_error
<li>Action: Diagnosis_update
<li>entered by: sasha 
<li>description is: During past 30 days the error rate was either 0% or <1%. We were not able to reproduce the error in SVXDAQ. The error rate is very low and seems to have a trend to decrease with time, so I'm declaring this ladder fixed. 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B0W2&layer=L1">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Wed Dec 7 19:08:08 2005 -->
Entered in Silicon database: <ul>
<li>Ladder: IB0W4L2 
<li>problem n: 960 
<li>Status: fixed
<li>Type: Chip_capid
<li>Action: Diagnosis_update
<li>entered by: sasha 
<li>description is: no more CAP_ID errors. call it fixed 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=ISL&wedge=B0W4&layer=L2">report</a></ul>
<!-- Author: Problem DB -->



<!-- Date: Wed Dec 7 22:27:25 2005 -->
<h3>Silicon Cosmics Run</h3> 
 
<p>During the evening there was a Silicon COSMICS run (Run # 208390 and 208391) using the COSMICS_SILICON_TAPE.  Most of the detector was biased for this run including silicon.  SVXMON looked fine; typical for a COSMICS run.  So I am satisfied the chips + DAQ chain is working. However one unusual thing was the large number of PINKIES in the bias lines for ISL.  SVX had them to a lesser degree and only for layers 2 & 4: ie- just the MICRON sensors.</p> 
 
<p>So we need to understand why so many ladders in ISL went PINK.   I am suspecting having the silicon warmer than usual for ~7days has had an effect on the BIAS currents.</p>
<!-- Author: Oscar & Ankush -->
<!-- Comment: Wed Dec  7 23;25;51 comment by...just smartmouthing ... -->
only the SVX/L00 cooling was put to -6, ISL remained at +6. However, if the detector was off over an extended time, that will change temperatures. so you may have some annealing in the ISL.  
<!-- Comment: Thu Dec  8 07;43;45 comment by...Ulrich -->
<br>
It is not inconceivable that temperature is the culprit. A quick look at the longer term history of the ISL temperature shows that all ISL temperatures are consistently 0.5 to 1 degree higher than with the other chiller (at comparable flows/pressures, etc.). We will investigate this further today.
<!-- Date: Wed Dec 7 22:38:50 2005 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7971&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7971  width='300' align='top'></a></td><td><p>This is an example of the large number of PINKIES and YELLOWS we are observing in IMON.  Note they are only in the BIAS lines => The ISL sensors.</p></td></tr></table>
<!-- Author: Ankush & Oscar -->



<!-- Date: Thu Dec 8 09:13:55 2005 -->
Entered in Silicon database: <ul>
<li>Ladder: IB4W0L4 
<li>problem n: 1584 
<li>Status: fixed
<li>Type: BIAS
<li>Action: Currents_investigated
<li>entered by: amitra 
<li>description is: <p>This entry is a reminder that the Power supply for this ladder is currently reading back 0.0.  This is just a readback problem.  We know the ladder can be biased.  See   <a href= 'http://www-cdfonline.fnal.gov/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=274&frame=2&anchor=14:52:14'> here</a> and  <a href= 'http://www-cdfonline.fnal.gov/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=274&frame=2&anchor=09:48:21'> here</a> in the Silicon E-log (9th & 10th November 2005)</p>  
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=ISL&wedge=B4W0&layer=L4">report</a></ul>
<!-- Author: Problem DB -->



<!-- Date: Thu Dec 8 10:00:58 2005 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7972&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7972  width='300' align='top'></a></td><td>ISL alcove temperatures before and after the chiller swap. All temperatures came back higher.</td></tr></table>
<!-- Author: Ulrich -->
<!-- Comment: Thu Dec  8 10;38;01 comment by...Eva & Ulrich -->
Eva and Stefano remembered that the controller of the ISL chiller had to be re-calibrated in the past. What was calibrated is the translation from control currents (4-20 mA) to temperatures (-25C - +25C). We will remind ourselves how to do the calibration. In the meanwhile, we lowered the ISL temperature setpoint to 5C.


<!-- Comment: Thu Dec  8 14;17;54 comment by...Eva, Jennifer, Ulrich -->
We discussed with Stefano and Warren the possible explanations:
<ul>
<li>The calibration ISL chiller is wrong. In the past, this happened only after the chiller control panel was replaced, but it is conceivable that the control panel has been touched during the repair work on the chiller. Unfortunately, the RAM technicians do not document their work in great detail.</li>
<li>The chiller is lacking freon. In this case we would expect a temperature drift over time.</li>
</ul>
Our plan: Observe temperatures until tomorrow morning. If they are stable: do the re-calibration.

<!-- Date: Thu Dec 8 11:51:14 2005 -->
<h3>Crashed PS-Gui!!!</h3> 
 
<p>Our lovely PS-Gui decided to run out of memory and crash.  O Joy </p> 
 
<p>Here&#39s a dump of message printed out on the terminal window.</p> 
 
<pre> 
<svxii@b0dasvx01>User: svxii 
Display: 
Attempting initialization of CAEN at svxinter.fnal.gov... 
Downloading /cdf/onln/home/svxii/daq/PSanywhere/PS.conf 
Loading startup files to the server.....Please be patient 
GUI Startup Done! 
Status change prohibited 
ch = 4 
pcStatus = 0 
status = 1 
channelStatus = 2 
If same do nothing 
If same do nothing 
If same do nothing 
Status change prohibited 
ch = 1 
pcStatus = 1 
status = 2 
channelStatus = -1 
Status change prohibited 
ch = 1 
pcStatus = 1 
status = 2 
channelStatus = -1 
If same do nothing 
Status change prohibited 
ch = 2 
pcStatus = 1 
status = 2 
channelStatus = -1 
Status change prohibited 
ch = 2 
pcStatus = 1 
status = 2 
channelStatus = -1 
Status change prohibited 
ch = 2 
pcStatus = 1 
status = 2 
channelStatus = -1 
If same do nothing 
Status change prohibited 
ch = 1 
pcStatus = 1 
status = 2 
channelStatus = -1 
Status change prohibited 
ch = 0 
pcStatus = 1 
status = 2 
channelStatus = -1 
getSiliconInfo:ERROR = 10 
If same do nothing 
Exception occurred during event dispatching: 
java.lang.OutOfMemoryError: 
        at gov.fnal.robin.BERsequence.toByteArray(BERsequence.java:130) 
        at gov.fnal.robin.rRequest.get_response(rRequest.java:382) 
        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$0(PWR.java:478) 
        at CAEN.PWR$resetValuesFromVMEThread.run(PWR.java:429) 
        at CAEN.PWR.resetValuesFromVME(PWR.java:475) 
        at CAEN.PSControlForm.refresh(PSControlForm.java:1626) 
        at CAEN.PSControlForm.access$0(PSControlForm.java:1609) 
        at CAEN.PSControlForm$1.actionPerformed(PSControlForm.java:751) 
        at com.sun.java.swing.Timer.fireActionPerformed(Timer.java:134) 
        at com.sun.java.swing.Timer$DoPostEvent.run(Timer.java:100) 
        at com.sun.java.swing.SystemEventQueueUtilities.processRunnableEvent(Sys                                                          temEventQueueUtilities.java:193) 
        at com.sun.java.swing.SystemEventQueueUtilities.access$0(SystemEventQueu                                                          eUtilities.java:189) 
        at com.sun.java.swing.SystemEventQueueUtilities$RunnableTarget.processEv                                                          ent(SystemEventQueueUtilities.java:230) 
        at java.awt.Component.dispatchEventImpl(Component.java:1812) 
        at java.awt.Component.dispatchEvent(Component.java:1744) 
        at java.awt.EventDispatchThread.run(EventDispatchThread.java:79) 
<svxii@b0dasvx01> 
</pre>
<!-- Author: Ankush -->
<!-- Comment: Thu Dec  8 14;44;47 comment by...boveia -->
<pre>This looks similar to the problems we had before we switched java versions.  Did we accidently switch back in the midst of all the computing maintenance going on?</pre>

<!-- Comment: Thu Dec  8 16;58;59 comment by...The return of the Great One -->
so I fixed this memory issue, Iguess
Changing in caencontrol.table file:
<pre>
addAlias(PS,"java -native  -ss100m -oss100m -ms16m  CAEN.PSControlForm")
</pre>
This should give it plenty of memory

<!-- Date: Thu Dec 8 15:11:54 2005 -->
Entered in Silicon database: <ul>
<li>Ladder: IB0W3L2 
<li>problem n: 717 
<li>Status: fixed
<li>Type: BIAS
<li>Action: Monitoring
<li>entered by: oscar 
<li>description is: After the last modification by Juan Pablo, IBIAS0 has been stable (or increasing as it was doing before). 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=ISL&wedge=B0W3&layer=L2">report</a></ul>
<!-- Author: Problem DB -->



<!-- Date: Thu Dec 8 15:14:17 2005 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7973&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7973  width='300' align='top'></a></td><td>This is the plot for the BIAS current in the ladder referred in the previous entry.</td></tr></table>
<!-- Author: Oscar -->

<!-- Date: Thu Dec 8 15:21:10 2005 -->
Entered in Silicon database: <ul>
<li>Ladder: IB1W0L3 
<li>problem n: 1510 
<li>Status: fixed
<li>Type: BIAS
<li>Action: Monitoring
<li>entered by: oscar 
<li>description is: This ladder has not still exceed the limits, so we declare it fixed. 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=ISL&wedge=B1W0&layer=L3">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Thu Dec 8 15:24:19 2005 -->
Entered in Silicon database: <ul>
<li>Ladder: IB3W1L1 
<li>problem n: 1568 
<li>Status: fixed
<li>Type: BIAS
<li>Action: Added_hdwdb
<li>entered by: oscar 
<li>description is: It didn't trip again since hockerization. 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=ISL&wedge=B3W1&layer=L1">report</a></ul>
<!-- Author: Problem DB -->



<!-- Date: Thu Dec 8 15:30:27 2005 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7974&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7974  width='300' align='top'></a></td><td>Bias0 current for IB4W1L1. Seems fine since limits were changed on 9/21/05</td></tr></table>
<!-- Author: Oscar/Ankush -->

<!-- Date: Thu Dec 8 15:32:04 2005 -->
Entered in Silicon database: <ul>
<li>Ladder: IB4W1L1 
<li>problem n: 1250 
<li>Status: fixed
<li>Type: Other
<li>Action: Diagnosis_update
<li>entered by: oscar 
<li>description is: Current BIAS looks fine for this ladder. You can take a look to <a href= 'http://www-cdfonline.fnal.gov/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=278&frame=2&anchor=15:30:27'> this plot</a>. 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=ISL&wedge=B4W1&layer=L1">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Thu Dec 8 15:46:00 2005 -->
Entered in Silicon database: <ul>
<li>Ladder: IB4W4L2 
<li>problem n: 1535 
<li>Status: needs_observation
<li>Type: BIAS
<li>Action: Diagnosis_update
<li>entered by: oscar 
<li>description is: It seems that the physics tail for this ladder is still (again?) low. We guess on under-depletion. 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=ISL&wedge=B4W4&layer=L2">report</a></ul>
<!-- Author: Problem DB -->



<!-- Date: Thu Dec 8 16:08:44 2005 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7977&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7977  width='300' align='top'></a></td><td>Bias Current for SB3W6L2 (Imon limits changed on 10/24/05). They are stable now.</td></tr></table>
<!-- Author: Oscar/Ankush -->


<!-- Date: Thu Dec 8 16:10:45 2005 -->
<center><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7978&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7979' ></a><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7975&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7976' ></a><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7984&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7985' ></a><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7982&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7983' ></a><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7980&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7981' ></a></center>
<!-- Author: Peter, Jonathan Lewis, Rick Tesarek,  Rainer -->
<!-- Comment: Thu Dec  8 16;16;10 comment by...Peter Dong, Jonathan Lewis, Marv Olson,  Rick J. Tesarek, RSW -->
<h2> More Diamonds!</h2>
<li> one diamond is deployed on the west between Q3 and Q4 on the top tesarek scintillator module with the A side facing CDF.
<li> one diamond is close to the E0 collimator at E11. This one will be readout by the BLM upgrade electronics. There is a test BLM nearby.
<!-- Date: Thu Dec 8 16:10:49 2005 -->
Entered in Silicon database: <ul>
<li>Ladder: SB3W6L2 
<li>problem n: 1508 
<li>Status: fixed
<li>Type: BIAS
<li>Action: Monitoring
<li>entered by: oscar 
<li>description is: After the Imon limits changed, Bias current has been stable, as shown in <a href= 'http://www-cdfonline.fnal.gov/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=278&frame=2&anchor=16:08:44'> this plot</a>. 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B3W6&layer=L2">report</a></ul>
<!-- Author: Problem DB -->




<!-- Date: Thu Dec 8 16:26:44 2005 -->
<table><tr><td><a href=/elog/notebooks/silicon/Thu_Dec__8_2005_162637.ps align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7990  align='top'></a></td><td>Looking at this plot, we decided that ladder IB4W4L4 is fine (no problem with under-depletion or pinholes). It was declared fixed in the database.</td></tr></table>
<!-- Author: Oscar/Antonio/Ankush -->

<!-- Date: Thu Dec 8 16:28:26 2005 -->
Entered in Silicon database: <ul>
<li>Ladder: IB4W5L0 
<li>problem n: 539 
<li>Status: fixed
<li>Type: pinhole
<li>Action: Monitoring
<li>entered by: oscar 
<li>description is: No signs of pinhole or under-depleted ladder in last physics run. Fin plot  <a href= 'http://www-cdfonline.fnal.gov/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=278&frame=2&anchor=16:26:44'> here</a> 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=ISL&wedge=B4W5&layer=L0">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Thu Dec 8 16:29:32 2005 -->
Entered in Silicon database: <ul>
<li>Ladder: IB4W5L0 
<li>problem n: 539 
<li>Status: fixed
<li>Type: pinhole
<li>Action: Monitoring
<li>entered by: oscar 
<li>description is: No signs of pinhole or under-depleted ladder in last physics run. Fin plot  <a href= 'http://www-cdfonline.fnal.gov/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=278&frame=2&anchor=16:26:44'> here</a> 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=ISL&wedge=B4W5&layer=L0">report</a></ul>
<!-- Author: Problem DB -->



<!-- Date: Thu Dec 8 16:39:37 2005 -->
<table><tr><td><a href=/elog/notebooks/silicon/Thu_Dec__8_2005_163935.ps align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7992  align='top'></a></td><td>ADCMon plot for one ladder that was suspicious of having a pinhole. Seems to be fine and without signsa of underdepletion. I declared as "fixed" in the PDB.</td></tr></table>
<!-- Author: Oscar -->

<!-- Date: Thu Dec 8 16:41:42 2005 -->
Entered in Silicon database: <ul>
<li>Ladder: IB4W3L4 
<li>problem n: 273 
<li>Status: needs_observation
<li>Type: pinhole
<li>Action: Monitoring
<li>entered by: oscar 
<li>description is: No signs of underdepletion or having a pinhole in last runs, as in <a href= 'http://www-cdfonline.fnal.gov/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=278&frame=2&anchor=16:26:44'> this plot</a>. 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=ISL&wedge=B4W3&layer=L4">report</a></ul>
<!-- Author: Problem DB -->




<!-- Date: Thu Dec 8 17:18:57 2005 -->
<pre>We just swapped VRB with serial #141 (svx01, slot 20) by VRB with serial #102. We did that in hope that it'll cure the problem with e1a0... we'll see.   </pre>
<!-- Author: Sasha/Ankush/tireless ex-SPL Marcel -->
<!-- Comment: Thu Dec 22 10;11;33 comment by...s -->
wrong firmware, note that the latest version is vrb5822P.hex.
<!-- Date: Thu Dec 8 17:41:08 2005 -->
Entered in Silicon database: <ul>
<li>Ladder: SB1W10L0 
<li>problem n: 1167 
<li>Status: needs_work
<li>Type: Chip_bit_error
<li>Action: Monitoring
<li>entered by: sasha 
<li>description is: The problem may be related within a VRB because we see d0 in  the raw data. So, we changed a VRB for this ladder. We'll see  if it cures the problem.  
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B1W10&layer=L0">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Thu Dec 8 18:00:34 2005 -->
Entered in Silicon database: <ul>
<li>Ladder: SB0W11L4 
<li>problem n: 101 
<li>Status: unfixable
<li>Type: Chip_bit_error
<li>Action: Diagnosis_update
<li>entered by: sasha 
<li>description is: I'm putting this ladder back to the previous category: 'unfixable'. My original motivation to it in 'needs_work' was that the problem might be related to light level and could be fixed by bit booster. After more careful examining of the previous entries, I realized that this is not the case. 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B0W11&layer=L4">report</a></ul>
<!-- Author: Problem DB -->



<!-- Date: Thu Dec 8 21:33:47 2005 -->
<h4>SB2W9L1 (e291) DVDD put to IGNORE in IMON</h4> 
 
<p>During the early evening I noticed the DVDD for SB2W9L1 (e291) went PINK.  Several CONFIGS, wedge power-cycles and hockerisations did not help.  I ran the ladder in SVXDAQ and the histograms look fine.</p> 
 
<p>So for the moment I have put this cell to IGNORE in IMON and I will see if it decides to return to normal in the morning.  I can see already the DVDD current slowly falling.</p>
<!-- Author: Ankush -->
<!-- Comment: Fri Dec  9 09;36;51 comment by...Ankush -->
<p>I have now un-ignored IMON DVDD cell for e291.  The current has reduced but it is still rather erratic.  But not PINK....yet....</p>
<!-- Date: Thu Dec 8 21:36:13 2005 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7994&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7995  width='300' align='top'></a></td><td><p>IMON DVDD history of SB2W9L1 (e291).  One feature of this graph is DVDD looks very noisy.  It should be flat and stable as we are only in STANDBY.  But you can see DVDD is starting to fall.</p></td></tr></table>
<!-- Author: Ankush -->


<!-- Date: Fri Dec 9 08:20:17 2005 -->
<h4>Espresso Machine Offline for maintanance</h4> 
 
<p>The espresso machine will under go its regular 10,000 espesso service.  So the macine will be taken offline for the morning.</p>
<!-- Author: The Saeco Techs -->
<!-- Comment: Fri Dec  9 13;34;22 comment by...The SAECO techs -->
<h2> Espresso machine is back </h2>
After a thorough cleaning and descaling procedure, the espresso machine is back. She is ready to serve more cups of pure pleasure (S.Hahn). 
<!-- Date: Fri Dec 9 09:34:50 2005 -->
<h4>Fri Dec 09 09:23:57 CST 2005     success: Channel4 SVX B3 W10 to STANDBY</h4> 
 
<p>10 mins so far.....<b>woo hoo!!!!!</b>  
<!-- Author: Ankush -->
<!-- Comment: Fri Dec  9 10;57;48 comment by...s -->
nice!


<!-- Date: Fri Dec 9 11:22:41 2005 -->
<h3>ISL chiller calibration</h3> 
We have re-calibrated the ISL chiller today. It was operating around its usual setpoint of 6C, but the actual temperatures were about 1 degree higher. The calibration works like this: 
<ul> 
<li>We use the PLC itself as the calibration current source. A remote setpoint of -25C is mapped to a current of 4 mA, and +25C corresponds to 20 mA.</li> 
<li>We follow the procedures of the Honeywell UDC 3300 controller manual (p. 229ff) to calibrate Input #2, the remote setpoint: choose 'Calib Input 2' from setup menu, dial in -25C, press button and wait, dial in +25C, press button and wait, done.</li> 
</ul> 
 
We do not yet know if the calibration worked as expected. The temperature reading is still off by about 1 degree. We will investigate...
<!-- Author: Eva, Jennifer, Warren, Stefano, Ulrich -->
<!-- Comment: Fri Dec  9 12;23;54 comment by...Eva H. -->
Looks like the recalibration didn't do the trick.  The setpoint is at 6C now but temps are ~1C higher like before. Hmmm.  Ankush biased ISL and we got several pinkies as the other day.  So I put the setpoint back to 5C so that the temps go down and silicon guys can do some studies this afternoon.  

<!-- Comment: Fri Dec  9 17;32;29 comment by...Eva, Jennifer, Ulrich -->
<br>
Some more thoughts about the ISL chiller calibration:
<ul>
<li>The symptom was: we choose a setpoint of 6C in iFix, the PLC transmits this value to the controller, and the controller shows a setpoint of 6C. The temperature reading which was regulated against the setpoint hovered around 6C. However, all other temperature sensors showed an increase.</li>
<li>Conclusion: we re-calibrated the wrong thing, i.e. the translation between the PLC signal and the chiller setpoint. What needs to be calibrated is the temperature sensor. There is a bias setting for the sensor which we could tweak.
<li>Scanning through the menus, we found one strange setting. The controller allows to set the actuation type for the setpoint input (#2). It should be set to "4-20 mA", but it shows "1-5 V". Unfortunately, the other controllers are a different model without that option (at least at the same place), and we do not have the manual at hand. Andy?</li>
</ul>
<!-- Date: Fri Dec 9 11:35:01 2005 -->
<h3>New version of traceSilicon available...from cdfdaq</h3> 
 
<p>Now we can write a <a href= 
'http://www-cdfonline.fnal.gov/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=278&frame=2&anchor=11:27:24'> 
CAEN-currents file</a> and PS-Gui can load it correctly we can now use traceSilicon to set the bias currents.  However that option was missing from the current version of traceSilicon.</p> 
 
<p>I asked Bill B to add an option to set the Bias current and it works!!  However for some reason this only works from cdfdaq user account.  So we will have to figure out why it can&#39t run from svxii.</p> 
 
<p>If you want to run the new version do the following:</p> 
 
<ul> 
<li>log in as cdfdaq (svxii has been added to the cdfdaq .k5login)</li> 
<li>source /cdf/cdf.cshrc</li> 
<li>setup hdwdb v2_0a</li> 
<li>traceSilicon</li> 
</ul> 
 
<p>So we will await the return of Uncle Sebastian from sunny Argentina to fix it for svxii.</p> 
 
<!-- Author: Ankush -->
<!-- Comment: Fri Dec  9 12;30;20 comment by...Sebastian -->
No need to 'source /cdf/cdf.cshrc' as cdfdaq, it's
already in the .cshrc file. I think it does not work as
svxii because it sets up the old source file. I just
tried as svxii with /cdf/cdf.cshrc and it looks to me
that it worked, I got a prompt: "iSet1 bias current ?"
(after that I reverted to the old settings).
When I get back I will finish the code migration and
there will be no more problems with the setups (hopefully).




<!-- Date: Sat Dec 10 23:34:44 2005 -->
<h3>COSMICS Silicon Run</h3> 
 
<p>The ISL Chiller setpoint was set to 5C in the hope this would drive the ISL detector volume temperature to the nominal 6C.  So just to check the DOIMs were still happy, I ordered a Silicon COSMICs run.</p> 
 
<p>We ran COSMICS with Silicon for about 45 minutes.  I looked at SVXMON and browsed the strip plots and ADCMON of some random ladders.  It would appear everything looks fine.  No obvious bit errors.  The SVXMON summary plot for CELL ID was its usual mixture of green and blue; no great swathes of red.  So it looks like this current ISL Temperature Setpoint is OK.</p> 
 
<p>Once thing I noticed again was after the Silicon was biased, there were some pinkies for  SVX Bias for layers 2 & 4 => The MICRON ladders.  They went away with time. But I don&#39t remember seeing this before.</p> 
 
<p>FYI: the relevant run number is 208667</p> 
<!-- Author: Ankush -->
<!-- Comment: Sat Dec 10 23;36;44 comment by...Ankush -->
<h4>SiliMON</h4>

<p>Forgot to mention I had SiliMON running.  It looks like the COSMICS script change was propagated through.  COSMICS Data seems to be piping into SiliMON. I even saw a point appear in the efficiency Vs time plot.</p>  


<!-- Comment: Sun Dec 11 21;41;03 comment by...Marcel -->
This behaviour of the Micron ladders is not entirely unexpected. The detector was bascially off for two weeks, this is something, the Microns do not really appreciate. They then show this turn-on behaviour. If you have biased the detector several times for long periods, this will go away. 
<!-- Date: Sat Dec 10 23:52:29 2005 -->
<center><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7996&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7996' width='300'></a><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7997&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7997' width='300'></a><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7998&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7998' width='300'></a><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7999&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-7999' width='300'></a></center>
<!-- Author: Ankush -->
<!-- Comment: Sat Dec 10 23;59;51 comment by...Ankush -->
<h4>History of V-Dvdd, I-Dvdd for e291 and e292</h4>

<p>The order of the plots from left to right are: I-Dvdd for e291, V-Dvdd for e291, I-Dvdd for e292 and V-Dvddd for e292.</p>

<p>You can see the variance of the Dvdd current for e291 has increased significantly since the detector was powered on.  A similar pattern can be seen for V-Dvdd for e291.  However the I-Dvdd for e292 is the same before and after the detector power on/off.  But its V-Dvdd has started to droop since the detector was powered up.</p>

<p>So the question now is this the pre-cursor of some fault or will this just die down with time.</p> 





<!-- Date: Sun Dec 11 07:57:43 2005 -->
<pre>I was paged because e3a4 tripped. I asked the aces to put it 
back to Stand-by and when they tried (from i Fix), the whole wedge tripped. I came to take a look. 
 
I have troubles to put the ladders (PC+0,1,2) on Stand-by since they keep tripping for aa while. They are stand-by now. However, seems that L4 refuses to get to stand-by. It tripped in DVDD Overcurrent or AVDDovercurrent. 
 
I talked with Ankush on the phone and we decided to leave it off until they close the arches and the plug (open for the XFT to access). 
 
 </pre>
<!-- Author: Oscar -->
<!-- Comment: Sun Dec 11 09;47;46 comment by...Oscar and Ankush -->
<h4>Silicon Voodoo</h4>

<p>So we waited for the detector to be closed up and then offered an ACE sacrifice to apease the Madam SVX.  It appears she was pleased and e3a4 is now back to STANDBY for 13minutes and counting.</p>

<p>One trick I tried was to issue a CONFIG to fib04 immediately e3a4 went to STANDBY.  Not sure if this helped but it made Oscar and I happy.</p> 

<!-- Comment: Sun Dec 11 09;49;18 comment by...Ankush & Oscar -->
<p>Forgot to mention we did a COLDSTART and ran for 5,000 events.  Silicon seems to be fine.</p>



<!-- Date: Mon Dec 12 08:49:55 2005 -->
<h4>Summary of the week</h4> 
 
<p> Quiet week, no beam, no collision, slept well :), still 
interesting for a newcomer:</p> 
 
<li> We switched to stand-by the detector. It came up well, although we have problems with a L00 ladder (LB1W3L3,fa33). Problem was fixed when we could access the PS which was swapped. Limits still to be tuned. 
</li><br> 
 
<li> Ankush checked some ladders that were suspicious after the mega-quench. 
</li><br> 
 
<li> SVX was set to -10 after being at -6. It turned out fine. This was done after the work on the ISL chiller vacuum pump from the previous week.<br> 
However, we are having troubles with the calibration of the controller: the temperature is higher than the set value. Trying a calibration didn't help, so we are making use of a temporary solution by setting the value lower than the desired... to get the correct one. 
</li><br> 
 
<li> Now we are able to update CAENcurrents in hdwdb and using "gino" file. 
</li><br> 
 
<li>Work on diamond installation went on</li><br> 
 
<li>Ladder SB3WAL4 (e3a4) came back finally (after detector was closed). It started tripping on Sunday morning (arches,plug and wall on S-E were oipen for work on XFT) and it came back onnSunday morning (after detector was closed again). Strange behaviour: this ladder seems to be a good reference for knowing collision hall status. And it provides data too :) 
</li><br> 
 
<li>SB2W9L1 (e291) has been showing DVDD erratic bahaviour (noise-like) for the last days and it is still like that. Observation may be needed when it is on</li><br> 
 
<li>We took a couple of Cosmics runs with Silicon in (everything fine for data-taking) and d-mon calibrations without beam. Waiting for the next store(s) to take data and perform calibrations.</li><br> 
 
<li>Minor issues: java scripts, software upgrades, fixed some ladders from the database, espresso machine shutdown. 
</li><br> 
  
<!-- Author: Oscar -->


<!-- Date: Mon Dec 12 08:54:46 2005 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-8000&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-8001  width='300' align='top'></a></td><td>SB2W9L1 (e291) become pinkie (DVDD) in one of its fluctuation. It is still showing erratic value.</td></tr></table>
<!-- Author: Oscar -->