<!-- Title: 12:19:15  Mon Feb 26 2007 -->
<!-- Crewchief: Satyajit (MPC) -->
<!-- Op1: Ulrich (SPL) -->
<!-- Op2: &nbsp; -->
<!-- Op3: &nbsp; -->
<!-- Op4: &nbsp; -->
<!-- Op5: &nbsp; -->
<!-- Op6: &nbsp; -->
<!-- Notes: -->
<pre>Other than the PS crate #15 issue let's hope for a smooth sailing!</pre>

<!-- Date: Mon Feb 26 17:40:59 2007 -->
Entered in Silicon database: <ul>
<li>Ladder: IB1W0L3 
<li>problem n: 1714 
<li>Status: fixed
<li>Type: BIAS
<li>Action: IMON_limits
<li>entered by: jgarcian 
<li>description is: Increasing limits for Bias0.<table border=1>
<tr><th>IMON LIMITS</th><th>Old</th><th>New</th></tr>
<tr><td><b>Nominal</b></td><td>122.0</td><td>150.0</td></tr>
<tr><td><b>Lower</b></td><td>0.5</td><td>0.5</td></tr>
<tr><td><b>Upper</b></td><td>150.0</td><td>190.0</td></tr></table> 
<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: Mon Feb 26 21:23:43 2007 -->
<center><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-10817&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-10818' ></a><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-10819&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-10820' ></a></center>
<!-- Author: Jose -->
<!-- Comment: Mon Feb 26 21;26;22 comment by...Jose -->
Nice pattern for the bias currents in SVX, again with luminosity <= 50 ×10<sup>30</sup> cm<sup>-2</sup>sec<sup>-1</sup>


<!-- Date: Mon Feb 26 21:38:58 2007 -->
<h3>Great MCR Planning!!!</h3> 
So Jose and I came in for the end of the store to adjust flows in ISL, and guess what, the end of store has been postponed by 1/2 hour or so. Thanks a lot for letting us know and screwing up our evening plans even more! 
<p> 
So the plan for the flow adjustment is: 
<ul> 
<li>Close the valves for CCE1 and PCE a little to equalize the pressure with the other lines</li> 
<li>Close the manual bypass valve on the ISL chiller to bring the pressure back into the regime where the automatic chiller bypass regulates the pressure.</li> 
<li>Retune the valves to get good flow to the system</li> 
And of course: do all this without tripping anything. 
</ul>
<!-- Author: Ulrich -->
<!-- Comment: Mon Feb 26 22;33;50 comment by...Ulrich -->
Our plan worked out. The automatic bypass is back at 20%, and the supply pressure is around 26.5 psi. The current valve settings are:
<ul>
<li>CCE1: 54%</li>
<li>CCE2: 75%</li>
<li>CCE3: 75%</li>
<li>CCE4: 75%</li>
<li>PCE: 90%</li>
</ul>
Flow-wise we are about back to where we started from: 1.75 lpm flow to CCE1, at around 13.0 psi COT face pressure. This is a little lower than before the access on Saturday, but we can certainly live with it.
<p>
Now that the overall flow is a little lower, I adjusted a bunch of iFix lower warning/alarm limits:
<ul>
<li>SVX_FT_PCESUP and SVX_FT_PCWSUP (SVX portcard flows): from 3.0/3.2 lpm to 2.8/3.0 lpm</li>
<li>ISL_FT_SUPPLY (ISL supply flow): from 45.0/50.0 lpm to 45.0/48.0 lpm</li>
</ul>
<!-- Date: Mon Feb 26 21:53:33 2007 -->
SB1W0L3, SB4W10L0 and SB3W10L0 are hitting their IMON bias limits. 
They will be bumped up tomorrow morning.
<!-- Author: Satyajit -->



<!-- Date: Mon Feb 26 22:43:35 2007 -->
Once we are at it, we have also rebooted SVXIICON (due in 2 days).
<!-- Author: Jose & Ulrich -->


<!-- Date: Tue Feb 27 01:10:25 2007 -->
At the end of scrapping LOSTP was around 7.5 kHz and was steadily 
ramping down. Around 6.5 kHz I OKeyed to ramp up silicon. TevMon 
shows the current rate to be 5.6 kHz.
<!-- Author: Satyajit -->


<!-- Date: Tue Feb 27 01:17:19 2007 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-10821&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-10822  width='300' align='top'></a></td><td><h4>Store 5246, Init Lumi 257 E30</h4> 
Silicon was included from the beginning. SVTSpyMon and SVXMon 
plots look OK.</td></tr></table>
<!-- Author: Satyajit -->

<!-- Date: Tue Feb 27 08:41:34 2007 -->
Entered in Silicon database: <ul>
<li>Ladder: IB2W0L1 
<li>problem n: 1560 
<li>Status: fixed
<li>Type: BIAS
<li>Action: IMON_limits
<li>entered by: satyajit 
<li>description is: Bumping up the BIAS1 upper limit from 150 -> 170.<table border=1>
<tr><th>IMON LIMITS</th><th>Old</th><th>New</th></tr>
<tr><td><b>Nominal</b></td><td>76.3951</td><td>150.0</td></tr>
<tr><td><b>Lower</b></td><td>0.5</td><td>0.5</td></tr>
<tr><td><b>Upper</b></td><td>150.0</td><td>170.0</td></tr></table> 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=ISL&wedge=B2W0&layer=L1">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Tue Feb 27 08:56:59 2007 -->
Entered in Silicon database: <ul>
<li>Ladder: SB3W10L0 
<li>problem n: 1942 
<li>Status: fixed
<li>Type: BIAS
<li>Action: IMON_limits
<li>entered by: satyajit 
<li>description is: Bumping up Bias upper limit in anticipation.<table border=1>
<tr><th>IMON LIMITS</th><th>Old</th><th>New</th></tr>
<tr><td><b>Nominal</b></td><td>48.8468</td><td>90.0</td></tr>
<tr><td><b>Lower</b></td><td>0.5</td><td>0.5</td></tr>
<tr><td><b>Upper</b></td><td>100.0</td><td>120.0</td></tr></table> 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B3W10&layer=L0">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Tue Feb 27 09:04:25 2007 -->
Entered in Silicon database: <ul>
<li>Ladder: SB4W10L1 
<li>problem n: 1943 
<li>Status: fixed
<li>Type: BIAS
<li>Action: IMON_limits
<li>entered by: satyajit 
<li>description is: Bumping up Bias upper limit.<table border=1>
<tr><th>IMON LIMITS</th><th>Old</th><th>New</th></tr>
<tr><td><b>Nominal</b></td><td>46.9499</td><td>95.0</td></tr>
<tr><td><b>Lower</b></td><td>0.5</td><td>0.5</td></tr>
<tr><td><b>Upper</b></td><td>100.0</td><td>120.0</td></tr></table> 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B4W10&layer=L1">report</a></ul>
<!-- Author: Problem DB -->



<!-- Date: Tue Feb 27 13:49:36 2007 -->
<h3>iFix Alarm Summary pages are being updated</h3> 
Should the shift crews ask you what the new numbers on the left of the SVX Alarm Summary page are about, Jim Loskot is working on a mechanism to make it more transparent when alarms are ignored. I tried to convince him that we should know about this work <em>before</em> he starts it, but I'm not sure if he got the message.
<!-- Author: Ulrich -->


<!-- Date: Tue Feb 27 14:14:17 2007 -->
Around 13:15 got a page that there are a bunch of yellows on  
SVXMon chip status map. I asked the ACE to issue an HRR while 
heading for the control room. The HRR didn't help, nor did a 
shepherd of b0fib07 followed by a reset of the corresponding  
VRB (in b0svx07 slot 19). The affected wedge was f32. Starting  
a new Run solved the problem. It turns out that this wedge 
didn't see data from the beginning of this Run (~ 40 mins).
<!-- Author: Satyajit, Jose, Ulrich -->


<!-- Date: Tue Feb 27 22:04:48 2007 -->
When I was driving home, they paged me (by mistake) because they had a lot of pinkies. I asked them to paste some of them in the e-log and look at the L1 trigger. I was going to comment something in the e-log when at home, but Ulrich has been faster than me <a href=http://www-cdfonline.fnal.gov/cgi/internal/elog/elog.pl?nb=2007&action=xe&page=174&time=21:39:18.200> e-log</a>.
<!-- Author: Jose -->
<!-- Comment: Tue Feb 27 22;29;39 comment by...Ulrich -->
Maybe it's time to ask the readers of this log again: <b>Any idea why we see collective jumps in the bias current during prescale changes???</b>


<!-- Comment: Wed Feb 28 10;28;02 comment by...Ignacio -->
My best theory: Increase of readout rate => larger heat dissipation from the digital part of the chip=> Temperature  increase => Bias current increase
<!-- Comment: Wed Feb 28 13;40;39 comment by...The real Grumpy aka The Old Yale aka Marcel -->
in Spring 2004, there has been a study by Rainer, SCN and myself to estimate the increase of DVDD depending on the L1 rate. As I recall right, the increase as not dramatical, so I'd be surprised (but hey, this detector already showed a lot of surprising features), if this would affect the temperatures. Just keep in mind, how slow the cooling system reacts compared to the trigger changes. Given, that these are CAENS, I'd rather suspect some feedback mechanism in the CAEN's. That would actually something you could check, even with a loadbox. <br>
Just an idea from the rainy island
<!-- Comment: Thu Mar  1 15;22;24 comment by...Ignacio -->
We do not need dramatic effects. One should bare in mind that the L1A rate  jump at 50 E30 with the present trigger table is  large, ~50 %.  We should make a study of the amount and distribution of the bias jump but my impression  is that it is a small step ~5-10 %.  Marcel, where could we find those DVDD vs L1A estimations?
<!-- Comment: Fri Mar  2 17;59;35 comment by...Marcel -->
the stuff should be in the elog, around june 2004, otherwise, i can dig the perl scripts out as well, if you can't find it. Just let me know then
 

<!-- Comment: Sat Mar  3 18;36;10 comment by...Ignacio -->
Thanks for the information, Marcel.
I believe <a href='http://www-cdfonline.fnal.gov/cgi/internal/elog/det-system-elog.pl?nb=silicon&action=copyentry&page=201&time=09:11:25'>this</a>  is the entry. I think the plots are quite self-explanatory. Unless I am mistaken, we get an increase of between 2.5-3 mA in DVDD current per 15 Khz increase and chip. It is as much as 40 mA per ladder in SVX L4. My impression is that this can give the 5-10 % increase in bias current given the exponential dependence on temperature. Anyway: <li> we should use this to compare when we have quantified the bias steps amount.</li>
<li> the 20=>30 KHz L1A step due to prescale change at 50E30 has disappeared from the latest trigger table.</li>
<!-- Date: Wed Feb 28 09:45:28 2007 -->
What was expected to be a record store ended up in a 
<a href= 
'/cgi/elog/elog.pl?nb=2007&action=view&page=176&frame=2&anchor=09:32:35.935'> 
quench</a>. 
The post-quench checkout went fine.  
<a href= 
'/cgi/elog/elog.pl?nb=2007&action=view&page=176&frame=2&anchor=09:39:06.089'> 
Here</a> is the BLM plots.
<!-- Author: Satyajit -->


<!-- Date: Wed Feb 28 09:55:24 2007 -->
<h3>New Candidates for Dropping Flows</h3> 
There are two new candidates for dropping flows: ISL PCE, and SVX PCW. We have adjusted the valve settings a little to compensate and will keep an eye on it, but note that we are already beyond 90% for those and may run into regulating limits soon. When I did yesterday's change to the lower limit on SVX PC flows, I should have done it to the ProSys alarms page at the same time. Now that limit is at 2.8 lpm too.  
<!-- Author: Ulrich -->



<!-- Date: Wed Feb 28 11:31:53 2007 -->
<h3>ISL B1W3L4 Bias0: One More Volt</h3> 
We have increased the Bias0 voltage for ISL B1W3L4 by another volt, from 46 V to 47 V. The ladder is holding it fine, and current read back from the supply is 46.7 V. We'll wait for David Stuart for feedback after the next store.
<!-- Author: Jose & Ulrich -->


<!-- Date: Wed Feb 28 13:37:11 2007 -->
<h2>Access summary for Crate 15</h2> 
We went down with Dervin and Roberto to check the settings on the crates in the collision hall, and confirm that Crate 15's problems are really due to the crate going bad.  Dervin and Roberto found everything they needed to know, then we got down to testing.  This is roughly the order of everything we tried: 
<ul> 
<li> Tried hockerizing again, crate 15 didn't come back. 
<li> Measured the outputs of the cables at the Pisa box.  The Pisa box <b>just</b> controls the interlock system, it doesn't connect to the reset.  The 5V enable signal comes into the Pisa box (actual value: 4.92V).  The Pisa box converts it to ~0V and passes that to the crate's interlock input. 
<li> Measured the output of the reset cable, and watched a hockerization signal.  The signal is low (~180mV) until the hockerization signal is sent.  The reset signal is sent from the same place as the 5V enable, so the reset signal looks like a 5V pulse (actual value on crate 15: 4.94V).  I also watched a hockerization on crate 16, there it was also 180mV when low and went to 4.59V when hockerized. 
<li> Switched the reset cables between crates 15 and 16, then hockerized both crates.  Crate 16 came back up, crate 15 did not.  Looks like the reset cable is fine. 
<li> Switched the CAENet controller cable between crates 15 and 16.  We also had Jose switch the cables at svxinter, so this was really just a test of the cable.  We hockerized both crates, 16 came back up and 15 did not.  CAENet cable appears fine. 
<li> I then tried hockerizing using the Reset button on the crate.  I did this three times, it came up the second time but not the first or third times. 
<li> I then tried turning the crate on/off with the power key.  It didn't even come back up when the power was turned on/off! 
<li> As a last step, we tried removing all the power supplies from the crate (pulled them out one inch so they weren't in contact with the backplane).  We then tried the on/off switch, the local reset button, and a hockerization from upstairs.  The crate never booted up.  So it's not a problem with the power supplies. 
<li> After putting the supplies back in, I had to hit the local reset button 5 times before the crate finally turned back on. 
</ul> 
When we were done, we powered up all the supplies in crates 15 and 16 again, they all look fine.  At this point I think it's safe to conclude <b>the problem is with the crate</b>.  We'll have to swap in our brand-spanking new spare crate from CAEN.  Unfortunately, that crate hasn't been tested yet (Dervin and crew just finished switching it over to 400 Hz power).  This afternoon Satyajit and I will check it out with supplies, hopefully everything works.<br> 
<h3>Now for e074...</h3> 
We requested a 3hr access so we'd also have time to check out e074.  This ladder started tripping last week on <a href= 
'http://www-cdfonline.fnal.gov/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=341&frame=2&anchor=16:40:32'>AVDD Overcurrent/Undervoltage</a>.  Given our shortage of SVX spares right now (and the high rate of failure lately, I think I've swapped 3 or 4 this month?) we decided to play musical SVX supplies.  The ladder e084 is out of the DB, but its power supply should be fine.  So today we swapped the power supplies for SB0W7 and SB0W8.  SB0W8 was in a tricky corner of the crate, I actually had to uncable SB0W9 as well just to get the power supply in/out.  After the swap, SB0W7 and SB0W8 both could be powered, and e074 has not yet tripped again.  Initially SB0W9 came back with really low DOIM currents, but we hockerized the crate and that brought the power supply back to normal.  Some limits on SB0W8 and SB0W7 need changing.  Hopefully this will have fixed the problem with e074.<br>
<!-- Author: Jen, Satyajit, Jose (and a guest appearance by Ankush :) -->
<!-- Comment: Wed Feb 28 13;42;54 comment by...The old Yale -->
I should have got a patent for that crazy idea :-)
And Jen called it a one-time stunt back in the old days

<!-- Comment: Wed Feb 28 13;53;34 comment by...Jen -->
Ah, the good ol' days... when supplies were plentiful and failures were rare.  I think those ended as soon as Grumpy took control of the silicon group... ;) and I took over power supplies from Reid...

<!-- Comment: Wed Feb 28 13;55;00 comment by...Jose -->
When testing e074 in SVXDAQ it tripped again on AVDD Overcurrent. We will leave it on for a while to see if it holds but probably we will have to take it out...  :(


<!-- Comment: Wed Feb 28 20;28;15 comment by...Jose -->
I will include back this ladder on the morning, it is likely that it will trip, so better if we are here to take it out.
<!-- Comment: Thu Mar  1 08;08;15 comment by...Grumpy -->
yes, the old days where Jen was still the youngest member of the group, showed great respect for the elderly never used and any bad language.  

<!-- Date: Wed Feb 28 14:00:46 2007 -->
While powering back crate 6 after the PS swap, ladder e090 tripped on DVDD softLimit.  
 
<pre> 
Wed Feb 28 13:20:13 CST 2007     Software protection trip: High  
DVDD Current  SVX B0 W9 L0 current 201.0 softLimit 150.0 
</pre> 
 
After recovering it is holding.
<!-- Author: Jose -->


<!-- Date: Wed Feb 28 15:14:42 2007 -->
We had to hockerize crate #13 while recovering SVX since SB3W8 was 
tripping on DVDD. ALl Alarms are unignored apart from the air separator level which is fluctuating on the upper warning limit.
<!-- Author: Roberto/Oscar/Ignacio -->


<!-- Date: Wed Feb 28 17:07:08 2007 -->
<h3>New crate fails testing :(</h3> 
The new crate started off strong - we had two supplies in, we could turn them on/off and see the voltages/currents, all the menu options were working.  We even strung a bunch of connected lemo cables all the way from the back room to the trigger room, so we could connect the crate to b0sint01 (the teststand equivalent of svxinter).  Using that, we were able to turn the supplies on/off and run a practice burn-in test through b0sint01, so the CAENet appears to work fine.  The crate failed the last test however... we tried to put supplies in every slot.  That's when we realized the last slot was misaligned.  We can't put a supply in that spot, it won't plug into the backplane because it doesn't go in squarely.<br> 
Unfortunately it's too late to take it over to Prep now, so we'll talk to Dervin in the morning and see if we can get an expedited repair job.  It should be relatively simple, just have to realign that last slot...<br> 
Upshot: we have to wait for the crate to be repaired, do a quick test of it again, and then we'll be ready for the swap.<br>
<!-- Author: Jen, Satyajit, Jose -->


<!-- Date: Wed Feb 28 18:32:35 2007 -->
We asked for a DPS-OFF run after the bias voltage for f134, bias0 was increased f134 from  46 to 47 V. This is the 
<a href='http://www-cdfonline.fnal.gov/java/cdfdb/servlet/RunSummary?RUN_NUMBER=235372'>run</a>.
<!-- Author: Jose/Ignacio -->


<!-- Date: Wed Feb 28 20:34:28 2007 -->
Entered in Silicon database: <ul>
<li>Ladder: SB0W7L0 
<li>problem n: 1544 
<li>Status: fixed
<li>Type: AVDD
<li>Action: IMON_limits
<li>entered by: jgarcian 
<li>description is: Power supply swap changing limits.<table border=1>
<tr><th>IMON LIMITS</th><th>Old</th><th>New</th></tr>
<tr><td><b>Nominal</b></td><td>307.0</td><td>340.0</td></tr>
<tr><td><b>Lower</b></td><td>290.0</td><td>323.0</td></tr>
<tr><td><b>Upper</b></td><td>320.0</td><td>353.0</td></tr></table> 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B0W7&layer=L0">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Wed Feb 28 20:37:05 2007 -->
Entered in Silicon database: <ul>
<li>Ladder: SB0W8L2 
<li>problem n: 1944 
<li>Status: fixed
<li>Type: AVDD
<li>Action: IMON_limits
<li>entered by: jgarcian 
<li>description is: PS swap changing limits.<table border=1>
<tr><th>IMON LIMITS</th><th>Old</th><th>New</th></tr>
<tr><td><b>Nominal</b></td><td>780.0</td><td>835.0</td></tr>
<tr><td><b>Lower</b></td><td>625.0</td><td>680.0</td></tr>
<tr><td><b>Upper</b></td><td>810.0</td><td>865.0</td></tr></table> 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B0W8&layer=L2">report</a></ul>
<!-- Author: Problem DB -->



<!-- Date: Wed Feb 28 20:54:11 2007 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-10824&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-10824  width='300' align='top'></a></td><td>Also West!?! I hope I am wrong and it is not what I think it is...</td></tr></table>
<!-- Author: Jose -->


<!-- Date: Wed Feb 28 22:31:06 2007 -->
<h3> Tevatron quench! Again... </h3> 
They have quenched while scraping. From the MCR e-log: 
<pre> 
22:10:43-   TeV quench at D4. - DJC 
-- Wed Feb 28 22:13:32 comment by...DJC --  D48U half-cell quench. 
-- Wed Feb 28 22:20:08 comment by...DJC --  The only high loss in the D4 house is at D49 which was 1 rad/s. 
</pre>
<!-- Author: Jose -->
<!-- Comment: Thu Mar  1 08;13;36 comment by...Satyajit -->
Sorry, forgot to post last night that the 
<a href=
'/cgi/elog/elog.pl?nb=2007&action=view&page=177&frame=2&anchor=22:19:59.624'>
post-quench checkout</a>
was fine.


<!-- Date: Thu Mar 1 09:01:15 2007 -->
Set e071, e081 and e082 DVDD currents to IGNORE on the IMON until 
we check/adjust their values with beam. e07 and e08 were swapped  
yesterday.
<!-- Author: Satyajit -->


<!-- Date: Thu Mar 1 10:23:22 2007 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-10825&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-10826  width='300' align='top'></a></td><td><h4>Store 5256. Init lumi 132e30</h4> 
After a couple of aborted stores we are finally taking data. 
Silicon was integrated from the beginning. SVTSpyMon and 
SVXMon plots look fine. Ladder e074 holding AVDD fine so far.</td></tr></table>
<!-- Author: Satyajit -->


<!-- Date: Thu Mar 1 10:52:42 2007 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-10827&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-10827  width='300' align='top'></a></td><td>At the beggining of the store a pinkie appeared in e074 Bias. 
Looks like the current has jumped up a bit after the swap. I 
would bump up the limit.</td></tr></table>
<!-- Author: Satyajit -->

<!-- Date: Thu Mar 1 10:58:45 2007 -->
Entered in Silicon database: <ul>
<li>Ladder: SB0W7L4 
<li>problem n: 1945 
<li>Status: fixed
<li>Type: BIAS
<li>Action: IMON_limits
<li>entered by: satyajit 
<li>description is: Bumping up bias upper limit<table border=1>
<tr><th>IMON LIMITS</th><th>Old</th><th>New</th></tr>
<tr><td><b>Nominal</b></td><td>213.345</td><td>270.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>275.0</td><td>300.0</td></tr></table> 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B0W7&layer=L4">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Thu Mar 1 11:21:52 2007 -->
Entered in Silicon database: <ul>
<li>Ladder: SB0W7L4 
<li>problem n: 1946 
<li>Status: fixed
<li>Type: BIAS
<li>Action: IMON_limits
<li>entered by: satyajit 
<li>description is: Bumping up bias upper limit<table border=1>
<tr><th>IMON LIMITS</th><th>Old</th><th>New</th></tr>
<tr><td><b>Nominal</b></td><td>213.345</td><td>270.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>275.0</td><td>300.0</td></tr></table> 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B0W7&layer=L4">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Thu Mar 1 13:07:28 2007 -->
Entered in Silicon database: <ul>
<li>Ladder: SB0W7L1 
<li>problem n: 1902 
<li>Status: fixed
<li>Type: DVDD
<li>Action: IMON_limits
<li>entered by: satyajit 
<li>description is: Changing the upper and lower DVDD settings due to a recent PS swap.<table border=1>
<tr><th>IMON LIMITS</th><th>Old</th><th>New</th></tr>
<tr><td><b>Nominal</b></td><td>37.0</td><td>110.0</td></tr>
<tr><td><b>Lower</b></td><td>25.0</td><td>100.0</td></tr>
<tr><td><b>Upper</b></td><td>55.0</td><td>125.0</td></tr></table> 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B0W7&layer=L1">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Thu Mar 1 13:13:19 2007 -->
Entered in Silicon database: <ul>
<li>Ladder: SB0W8L1 
<li>problem n: 1947 
<li>Status: fixed
<li>Type: DVDD
<li>Action: IMON_limits
<li>entered by: satyajit 
<li>description is: Changing the DVDD limits due to a PS swap<table border=1>
<tr><th>IMON LIMITS</th><th>Old</th><th>New</th></tr>
<tr><td><b>Nominal</b></td><td>113.475</td><td>45.0</td></tr>
<tr><td><b>Lower</b></td><td>90.0</td><td>35.0</td></tr>
<tr><td><b>Upper</b></td><td>135.0</td><td>55.0</td></tr></table> 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B0W8&layer=L1">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Thu Mar 1 13:17:56 2007 -->
Entered in Silicon database: <ul>
<li>Ladder: SB0W8L2 
<li>problem n: 1948 
<li>Status: fixed
<li>Type: DVDD
<li>Action: IMON_limits
<li>entered by: satyajit 
<li>description is: Changing DVDD limits due to a recent PS swap.<table border=1>
<tr><th>IMON LIMITS</th><th>Old</th><th>New</th></tr>
<tr><td><b>Nominal</b></td><td>152.531</td><td>95.0</td></tr>
<tr><td><b>Lower</b></td><td>110.0</td><td>70.0</td></tr>
<tr><td><b>Upper</b></td><td>205.0</td><td>115.0</td></tr></table> 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B0W8&layer=L2">report</a></ul>
<!-- Author: Problem DB -->



<!-- Date: Thu Mar 1 13:59:40 2007 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-10828&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-10828  width='300' align='top'></a></td><td>The AVDD current for e074 was found very close to the hardware 
trip limit of 1400 mA. Changed the limit to 1600. In the  
history plot the current is seen shooting up beyond 1400. Is 
there a latency for the hardware trip limit to act?</td></tr></table>
<!-- Author: Satyajit, Ignacio, Jose -->
<!-- Comment: Thu Mar  1 14;15;25 comment by...Satyajit -->
This can't be true. I have seen the modules trip instantly when 
V,I go above limits.

<!-- Date: Thu Mar 1 14:20:31 2007 -->
Entered in Silicon database: <ul>
<li>Ladder: SB0W7L4 
<li>problem n: 1253 
<li>Status: needs_work
<li>Type: AVDD
<li>Action: Diagnosis
<li>entered by: satyajit 
<li>description is: The AVDD current is close to the hardware limit of 1400 mA. Increased it to 1600 mA. See the <a href= '/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=342&frame=2&anchor=13:59:40'> e-log entry</a>.  
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B0W7&layer=L4">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Thu Mar 1 14:21:38 2007 -->
Entered in Silicon database: <ul>
<li>Ladder: SB0W7L4 
<li>problem n: 1253 
<li>Status: needs_work
<li>Type: AVDD
<li>Action: Diagnosis
<li>entered by: satyajit 
<li>description is: The AVDD current is close to the hardware limit of 1400 mA. Increased it to 1600 mA. See the <a href= '/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=342&frame=2&anchor=13:59:40'> e-log entry</a>.  
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B0W7&layer=L4">report</a></ul>
<!-- Author: Problem DB -->




<!-- Date: Thu Mar 1 15:35:37 2007 -->
We have lowered the alarm/warning limits for all ISL flows to the level we already had for CCE1 and PCE: warning at 1.5 lpm, alarm at 1.4 lpm. Note that the PLC trip limit is 1.3 lpm for the CCE and CCW lines, and 0.8 lpm for the PCE and PCW lines. Of course, this just suppresses warnings and does not solve the problem of drooping flows. 
<!-- Author: Ulrich -->


<!-- Date: Thu Mar 1 16:07:14 2007 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-10829&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-10829  width='300' align='top'></a></td><td>Judging by the two new lines (SVX PCW, CCW3) the scale of the drop is slow, 0.4-0.5 lpm per week. Difficult to say anything for ISL PCE since we have been massaging  this one a lot.</td></tr></table>
<!-- Author: Ignacio -->


<!-- Date: Thu Mar 1 16:49:12 2007 -->
<center><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-10830&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-10830' width='300'></a><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-10831&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-10831' width='300'></a><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-10832&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-10832' width='300'></a></center>
<!-- Author: Ignacio -->
<!-- Comment: Thu Mar  1 16;55;08 comment by...Ignacio -->
The lines that seem to loosing flow in a week time scale  are 
SVX PCW, ISL CCW1 and ISL CCW3. Additionally we know ISL PCE is loosing flow for a given valve setting and ISL CCE2 is next in touchiness to ISL CCE1. 


<!-- Date: Thu Mar 1 18:25:16 2007 -->
<h3>We have a spare crate!</h3> 
Thanks to Dervin, who pounded straight that last slot which was misaligned!  I tested the crate by: 
<ul> 
<li> Hooking it up to b0sint01 and running commands from there (CAENet works) 
<li> Putting a L00 supply in every slot and taking it through a full loadbox test (trips on overvoltage, overcurrent, run a quick burn-in test) 
</ul> 
I only tested the 5 odd-numbered slots, since those are the only ones that will get used once we put the crate in.  Everything looks fine.  I'd say this is a good crate, and we're ready to swap out crate 15 as soon as we get our 4-hr access.<br>
<!-- Author: Jen, Jose, Ignacio, Satyajit -->


<!-- Date: Thu Mar 1 19:20:17 2007 -->
<p>There has been b0spool problems today that translated in the loss of PSGui/IMON since they both look at the area /cdf/onln/data/  
and could not reach it. Fortunately we went to standby beforehand. </p> 
<p> 
We have loaded the new LV file with the AVDD trip limit at 1600 for e074. We did produce a new CAENvolts.dat with bias0 f134 at 48 V, but have not yet loaded into PSGUi since the b0spool problem  was solved on the spot and we went back to data taking.  We should the new  CAENvolts.dat whenever possible.</p>
<!-- Author: Jose/Ignacio -->


<!-- Date: Fri Mar 2 03:25:27 2007 -->
After the end of store, I came in to increase the flow on the CCW3 line. The flow for this line has been a bit too low lately, reaching the warning level. I opened the valve from 80% to 85% (in 1% steps). The flow increased from 1.62 to 1.88 lpm, also the preassure increased slightly now it is at 6.4 psi.
<!-- Author: Jose -->


<!-- Date: Fri Mar 2 05:30:13 2007 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-10836&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-10836  width='300' align='top'></a></td><td><h3> Tevatron quench, integration dose alarm and solenoid off </h3> 
It seemed that the beam was coming soon, so I decided to stay for the shot setup after the flow adjustment. I was in the office when the Rob (ACE) came to tell me that the integrated dose alarm started beeping. When I entered the control room the tevatron quenched. 
<pre> 
04:27:21-   Tev quench during scraping. - djinn 
-- Fri Mar 2 04:27:55 comment by...djinn --  B0 low betas BA and BB are the offending houses. 
-- Fri Mar 2 04:31:26 comment by...djinn --  B26L also quenched. 
-- Fri Mar 2 04:32:47 comment by...djinn --  B2 also initiated a fast beam abort.  
-- Fri Mar 2 05:07:44 comment by...djinn --  It looks like the tunes went to a bad place. The alarms viewer does not show any smoking guns - nothing obvious until 04:26:50, which is when things trip off in response to the quench.  
</pre> 
 
Looking to the integrated doses it does not seemed that the radiation was large and everything looks fine in the detector. A better check can be done during the morning (in a couple of hours). 
 
They have a problem with the solenoid and now it is OFF. They are trying to repare it: 
<pre> 
Fri Mar 2 03:34:16  the cryo east dry engine stoped running on high temp limit override - Dean 
</pre> 
 
It should be back up in an hour or so.</td></tr></table>
<!-- Author: Jose -->
<!-- Comment: Fri Mar  2 08;13;56 comment by...Ulrich -->
The Rad Abort system did its job and pulled an integrated dose alarm. The dose integrated over the last minute before the abort exceeds 19 rad for SVRAD2 (East Inner BLM).


<!-- Date: Fri Mar 2 09:02:36 2007 -->
<h3>Access</h3> 
We have two hour access after the quench. We are going in to adjust the potenciometer for ISL PCE since we are at 92 % and only 1.5 lpm are going through. 
<!-- Author: Ulrich/Ignacio/Saty -->
<!-- Comment: Fri Mar  2 10;39;41 comment by...Ulrich -->
<h3>Happy Retirement: Access Report and More News on the Valve</h3>
Warren and I used the opportunity to tune the potentiometer on ISL PCE. In preparation for that I closed the valve a little, knowing that the low flow trip is at 0.8 lpm. So we switch off ISL and L00 before. What I overlooked is that the QuadLog has a trip limit of 1.0 lpm across the board, also for PortCards. So we tripped the racks again, mea maxima culpa! Del, Andy, and I will decide if we want this QuadLog logic changed at some point.
<p>
The access went well, Warren first turned the pot by 1/2 turn, which almost tripped the flow (13.6 psi), the I reduced the valve opening. I reduced it a little too much, and all other flows started oscillating. Warren then did two more carefull 1/4 turns, and now the flow is back to more than 2.0 lpm at 77% valve opening. Note however that we could run out of headroom nonetheless. 
<p>
We recovered fine from the rack trip. CAEN crate #15 needed a bunch of hockerizations to come back in line, but it was finally fine. We have also hockerized CAEN crate #6 because of the usual DOIM pinkies in e08x. We got a little nervous when we could not power anything in East ISL, but Ignacio found that we had forgotten to acknowledge the ISL PS trip that happened during the access. The HDI of e274 didn't config properly, but power-cycling the wedge brought it back in line, too.
<p>
Del provided some more details on the e-valve business:
<ul>
<li>The 4 spare valves we ordered are expected for March 22.</li>
<li>The order for 24 more valves will go out today.</li>
<li>The valve controller is made such that the stem is constantly oscillating, at a frequency of 200-300 Hz. The factory setting is 300 Hz, but it could be that the valve operation is more stable at 200 Hz. The frequency can be adjusted with a potentiometer.</li>
<li>According to the Asco technical support, the lifetime of such a valve is about 3 years. No wonder the valves start failing all over. This feature is not documented on the companys spec sheets, and apparently, nobody in CDF thought of it either. So swapping out all valves during the summer shutdown is a no-brainer.</li>
</ul>


<!-- Date: Fri Mar 2 11:16:24 2007 -->
<center><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-10837&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-10837' width='300'></a><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-10838&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-10838' width='300'></a><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-10839&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-10839' width='300'></a><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-10840&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-10840' width='300'></a></center>
<!-- Author: Ignacio -->
<!-- Comment: Fri Mar  2 16;16;41 comment by...Ignacio -->
Normal lloking SVXMon in cosmics data. 



<!-- Date: Fri Mar 2 23:14:20 2007 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-10841&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-10842  width='300' align='top'></a></td><td><h4>Store 5259, Init lumi 178e30</h4> 
Silicon was included from the beginning. SVTSpyMon and 
SVXMon plots look fine.</td></tr></table>
<!-- Author: Satyajit -->


<!-- Date: Sat Mar 3 08:01:06 2007 -->
<h3>Yet another TeV abort!</h3> 
Looks like this will be a record shift with max. Tev aborts. 
The <a href= 
'/cgi/elog/elog.pl?nb=2007&action=view&page=184&frame=2&anchor=06:23:58.367'> 
post-quench checkout</a> was fine.  
<!-- Author: Satyajit -->


<!-- Date: Sat Mar 3 09:27:35 2007 -->
<h3>Cooling System Adjustments</h3> 
I have made some adjustments to alarm/warning limits: 
<ul> 
<li>The upper warning limit for the SVX air separator level is now at 24 inches (from 23 inches) to account for the coolant refill. The alarm is still at 25 inches.</li> 
<li>The lower SVX portcard flow limits are now 2.7 lpm (warning, from 3.0 lpm) and 2.5 lpm (alarm, from 2.8 lpm). There is still enough flow to the portcards, and their temperatures are stable.</li> 
<li>I have fixed a bug in <tt>AlmMon.exe</tt>. When I rewrote the program to include alarm counting, I forgot one counter increment. This resulted in empty SVX warning messages.</li> 
</ul>
<!-- Author: Ulrich -->


<!-- Date: Sat Mar 3 09:41:26 2007 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-10843&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-10843  width='300' align='top'></a></td><td>AVDD current for e329 is getting erratic</td></tr></table>
<!-- Author: Ulrich -->

<!-- Date: Sat Mar 3 09:43:35 2007 -->
Entered in Silicon database: <ul>
<li>Ladder: SB3W9L2 
<li>problem n: 1837 
<li>Status: needs_observation
<li>Type: AVDD
<li>Action: IMON_limits
<li>entered by: husemann 
<li>description is: The AVDD current for e392 is getting erratic (see <a href= 'http://www-cdfonline.fnal.gov/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=342&frame=2&anchor=09:41:26'> here</a>). Bumping up the upper limit for now.   <table border=1>
<tr><th>IMON LIMITS</th><th>Old</th><th>New</th></tr>
<tr><td><b>Nominal</b></td><td>825.0</td><td>840.0</td></tr>
<tr><td><b>Lower</b></td><td>808.0</td><td>808.0</td></tr>
<tr><td><b>Upper</b></td><td>833.0</td><td>850.0</td></tr></table> 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B3W9&layer=L2">report</a></ul>
<!-- Author: Problem DB -->



<!-- Date: Sat Mar 3 13:43:55 2007 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-10846&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-10846  width='300' align='top'></a></td><td><h3> Another store another INTEGRATED DOSE ALARM !</h3> 
They paged everybody because they had another integrated dose alarm (second one this week). It happened while scraping as previous time, but so far the beam is still in... The plot shows the radiation integrated during the time of the alarm. Radiation became a little bit more stable after the initial jump, silicon was in standby all the time. </td></tr></table>
<!-- Author: Jose -->
<!-- Comment: Sat Mar  3 14;04;00 comment by...Ulrich (RadCo/Silicon Cooling pager) -->
<table border=0><td><tr><td bgcolor=#e0e030>Seems that the RadCo pager (266-2713) is broken. Please page my other pager (Silicon Cooling, 218-8626) instead.</td></tr></td></table>
<!-- Comment: Sat Mar  3 14;08;19 comment by...Jose -->
I hope we will not need to do it... 
<!-- Comment: Sun Mar  4 09;52;32 comment by...Ulrich -->
Here is an explanation from the Lord of the Tevatron:
<pre>
Yes, the proton tunes have been landing too close to the 7/12 resonance in several recent stores, causing very poor proton lifetime that you see as larger than usual doses during scraping.  Putting the tunes in the desired places reduces that losses very quickly.  I don't know how we got so far off; having big changes in pbar intensities from store to store doesn't make it easier to put in changes between stores.
</pre>
<!-- Date: Sat Mar 3 13:57:01 2007 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-10847&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-10847  width='300' align='top'></a></td><td><h3> Store 5261 </h3> 
After the initial problem with the radiation alarm when they finished scraping they had high proton losses. Scico called the MCR to ask what was happening and they corrected the losses: 
<pre> 
13:26:06- Store 5261 colliding. Proton losses are high. Bruce Hanna happened to be here and he is tuning on the proton horizontal tune. Raising it is bringing the losses down quickly. - ds 
</pre> 
Silicon was included when the losses where small and TeVMon was happy. The store came in with initial luminosity of 175e30. SVTSpyMon and SVXMon look fine. 
</td></tr></table>
<!-- Author: Jose -->
<!-- Comment: Sat Mar  3 15;43;27 comment by...Satyajit -->
<pre>Thanks Jose, for taking over! Sorry, I was outside with my pager
but somehow didn't get the musical beep. While driving back I heard
a single beep and realized I have a page.</pre>




<!-- Date: Sun Mar 4 10:26:16 2007 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-10848&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-10849  width='300' align='top'></a></td><td><h4>Store 5262. Init Lumi 121e30</h4> 
SVTSpyMon and SVXMon plots look ok. I have instructed the CO 
to add a comment to e-log after checking the SVXMon plots at 
the beginning of every Run. So far so good.</td></tr></table>
<!-- Author: Satyajit -->


<!-- Date: Sun Mar 4 10:51:10 2007 -->
<h4>Crate 3 spontaneous switch off!</h4> 
AutoHocker fixed it. Here is the  
<a href= 
'/cgi/elog/elog.pl?nb=2007&action=view&page=188&frame=2&anchor=10:39:09.440'> 
e-log entry</a>. 
<!-- Author: Satyajit -->


<!-- Date: Sun Mar 4 14:59:47 2007 -->
Got paged because of a low flow alarm for SVX PCW. I have changed the iFix warning/alarm limits yesterday but forgot the Process Systems alarm which were still at 2.8 lpm. I have called the cryo operator and asked him to lower his limit to 2.5 lpm as well. We can adjust flows after this store is dropped, presumably tomorrow morning.
<!-- Author: Ulrich -->
<!-- Comment: Sun Mar  4 18;50;32 comment by...Jose -->
<pre>Thanks Ulrich! The plan is still to drop the store tomorrow morning. I will do that in the morning.</pre>
<!-- Date: Sun Mar 4 17:03:46 2007 -->
Aaaachtung! IBias1 of IB0W5L1 creeping up, see 
<a href= 
'http://www-cdfonline.fnal.gov/cgi/elog/elog.pl?nb=2007&action=view&page=189&frame=2&anchor=16:59:57.734'> 
elog </a> 
 
  
<!-- Author: Scico von Koepenick -->


<!-- Date: Sun Mar 4 17:35:09 2007 -->
<h4>Crate 8 spontaneous switch off!</h4> 
Autohocker fixed it. Here is the 
<a href= 
'/cgi/elog/elog.pl?nb=2007&action=view&page=189&frame=2&anchor=16:59:38.277'> 
e-log entry</a>.  
<!-- Author: Satyajit -->

<!-- Date: Sun Mar 4 17:57:09 2007 -->
Entered in Silicon database: <ul>
<li>Ladder: IB0W5L2 
<li>problem n: 1949 
<li>Status: fixed
<li>Type: BIAS
<li>Action: IMON_limits
<li>entered by: satyajit 
<li>description is: Increasing IBIAS1 upper limit.<table border=1>
<tr><th>IMON LIMITS</th><th>Old</th><th>New</th></tr>
<tr><td><b>Nominal</b></td><td>53.7968</td><td>100.0</td></tr>
<tr><td><b>Lower</b></td><td>0.5</td><td>0.5</td></tr>
<tr><td><b>Upper</b></td><td>100.0</td><td>120.0</td></tr></table> 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=ISL&wedge=B0W5&layer=L2">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Sun Mar 4 18:06:10 2007 -->
Entered in Silicon database: <ul>
<li>Ladder: IB2W0L3 
<li>problem n: 1688 
<li>Status: fixed
<li>Type: BIAS
<li>Action: IMON_limits
<li>entered by: satyajit 
<li>description is: Increasing the BIAS1 upper limit.<table border=1>
<tr><th>IMON LIMITS</th><th>Old</th><th>New</th></tr>
<tr><td><b>Nominal</b></td><td>17.0</td><td>190.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>200.0</td><td>220.0</td></tr></table> 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=ISL&wedge=B2W0&layer=L3">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Sun Mar 4 18:14:27 2007 -->
Entered in Silicon database: <ul>
<li>Ladder: SB4W4L1 
<li>problem n: 1950 
<li>Status: fixed
<li>Type: AVDD
<li>Action: IMON_limits
<li>entered by: satyajit 
<li>description is: Increasing the (original) AVDD upper limit.<table border=1>
<tr><th>IMON LIMITS</th><th>Old</th><th>New</th></tr>
<tr><td><b>Nominal</b></td><td>498.638</td><td>510.0</td></tr>
<tr><td><b>Lower</b></td><td>490.0</td><td>490.0</td></tr>
<tr><td><b>Upper</b></td><td>505.0</td><td>560.0</td></tr></table> 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B4W4&layer=L1">report</a></ul>
<!-- Author: Problem DB -->




<!-- Date: Sun Mar 4 23:19:14 2007 -->
Was paged by (our ex-comrade) SciCo about 3 bias pinkies which  
appeared within a few minutes of each other. He has put these cells 
to IGNORE for the time being. I will bump up the limits tomorrow 
morning, wherever required.  
<!-- Author: Satyajit -->


<!-- Date: Sun Mar 4 23:22:04 2007 -->
Was paged by (our ex-comrade) SciCo about 3 ISL bias pinkies, which 
appeared within a few minutes of each other. He has put these cells 
to IGNORE for the time being. I will bump up the limits tomorrow 
morning, wherever required.
<!-- Author: Satyajit -->


<!-- Date: Mon Mar 5 08:19:43 2007 -->
While going to end of store configuration communication to crate 15 
was lost. The shift crew tried to hockerize from the iFix panel. 
Ignacio had to manually hockerize to bring it back. Here is the 
<a href= 
'/cgi/elog/elog.pl?nb=2007&action=view&page=190&frame=2&anchor=07:57:24.095'> 
e-log entry</a>.  
<!-- Author: Satyajit -->
<!-- Comment: Mon Mar  5 09;04;12 comment by...Ignacio -->
I pushed the button 30 times, 20 was not enough this time.
<!-- Date: Mon Mar 5 08:20:55 2007 -->
<h3>A 3 hrs access coming up</h3> 
We will do PC west valve adjustments.
<!-- Author: Satyajit -->



<!-- Date: Mon Mar 5 09:32:35 2007 -->
<h3>Week Summary</h3><p> 
<h4>Monday</h4> 
<ul> 
 <li><a href= 
'/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=342&frame=2&anchor=21:38:58'> 
Flow adjustment</a> to let the automatic chiller bypass to control 
     the flows in ISL.</li> 
</ul> 
 
<h4>Tuesday</h4> 
<ul> 
 <li>Store 5246, Init Lumi 257 E30.</li> 
 <li>A yellow block in SVXMon ISL/L00 chip status map went unnoticed by 
     the shift crew. Updated documentation to impose check at the  
     beginning of every run.</li> 
 <li>Synchronized bias current jump (pinkies) w/ L1A rate change. 
<a href= 
'/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=342&frame=2&anchor=22:04:48'> 
E-log entry</a>.</li> 
</ul> 
 
<h4>Wednesday</h4> 
<ul> 
 <li>Store 5248 ended with a quench</li> 
 <li>ISL PCE and SVX PCW now have dropping flows. 
 <li>4 hrs access. The crate 15 
<a href= 
'/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=342&frame=2&anchor=13:37:11'> 
saga</a>. e074 swap.</li> 
 <li>New crate (for crate 15 swap) shows problem.</li> 
 <li>Tevatron quench.</li> 
</ul> 
 
<h4>Thursday</h4> 
<ul> 
 <li>Store 5256. Init lumi 132e30</li> 
 <li>Hardware trip limit for e074 AVDD current increased 1400 -&gt; 1600.</li> 
 <li>More <a href= 
'/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=342&frame=2&anchor=15:35:37'> 
flow adjustments</a>.</li> 
 <li>Spare PS crate passes tests</li> 
</ul> 
 
<h4>Friday</h4> 
<ul> 
 <li><a href= 
'/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=342&frame=2&anchor=05:30:13'> 
Tevatron quench</a>. Integration dose alarm and solenoid off.</li> 
 <li>Access</li> 
 <li>Store 5259, Init lumi 178e30</li> 
</ul> 
 
<h4>Saturday</h4> 
<ul> 
 <li>Tevatron abort</li> 
<li>INTEGRATED DOSE ALARM !</li> 
</ul> 
 
<h4>Sunday</h4> 
<ul> 
</ul> 
 
<h4>Monday</h4> 
<ul> 
</ul> 
 
<p>
<!-- Author: Satyajit -->


<!-- Date: Mon Mar 5 12:08:04 2007 -->
<center><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-10850&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-10850' width='300'></a><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-10851&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-10851' width='300'></a></center>
<!-- Author: Oscar -->
<!-- Comment: Mon Mar  5 12;10;36 comment by...Oscar (et al) -->
Results from the bias Scan for ladder LB1W1L0 (fa10) for the last scan and one taken before the voltage limit was changed (left). We observe that although the nominal voltage was change, it looked that a shift of the nominal "zero" also occured. Same behaviour is observed for Ladder 1 and 2 in this wedge.


<!-- Date: Mon Mar 5 12:11:59 2007 -->
<center><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-10853&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-10853' width='300'></a><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-10852&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-10852' width='300'></a></center>
<!-- Author: Oscar -->
<!-- Comment: Mon Mar  5 12;16;24 comment by...Oscar (et al) -->
At the same time that we observed the shift described in prtevious entry for wide ladders in wedge fa1* we observed an apparent shift in wedge fa0* in the oppposite direction. The two PS are in different crates and it is unclear what is happening with this ladders in fa0*. Checks on ladder LB1W0L0 (fa00) seems that when we are in stand-by is not biased (a worry for a while) since current is zero.<br>
It should be noted that this ladders are related to crate 15, which has been giving troubles for a while.