<!-- Title: 14:55:24  Mon Jun 12 2006 -->
<!-- Crewchief: Sasha (MPC) -->
<!-- Op1: Ankush (SPL) -->
<!-- Op2: The Silis -->
<!-- Op3: &nbsp; -->
<!-- Op4: &nbsp; -->
<!-- Op5: &nbsp; -->
<!-- Op6: &nbsp; -->
<!-- Notes: -->
<h4>Waiting for good beam</h4> 
 
<p>We now await for good beam....until then we sit out...</p>


<!-- Date: Mon Jun 12 18:28:20 2006 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-8724&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-8724  width='300' align='top'></a></td><td><p>E-Log Abuse.  I am using this for graphics storage.</p></td></tr></table>
<!-- Author: Ankush -->


<!-- Date: Mon Jun 12 18:31:09 2006 -->
<h3>Possible 36x36 store tonight</h3> 
 
<p>Apparently we will have a 36x36 store sometime tonight.  Silicon will not be in...it's not even on(!).  However I will be here to see how things look beam-wise.</p>
<!-- Author: Ankush  -->


<!-- Date: Mon Jun 12 19:00:38 2006 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-8725&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-8725  width='300' align='top'></a></td><td><p>More E-Log abuse: Another plot needed for ACE Talk.</p></td></tr></table>
<!-- Author: Ankush -->


<!-- Date: Mon Jun 12 19:05:56 2006 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-8726&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-8726  width='300' align='top'></a></td><td><p>Even more E-log Abuse: BLM plot for ACE Talk</p></td></tr></table>
<!-- Author: Ankush -->


<!-- Date: Tue Jun 13 00:09:56 2006 -->
<h3>Store 4759</h3> 
 
<p>Yes we have a 36x36 store !!!.  The intial lumi was 29.35e30...not super-duper, but a decent value.  Shot set up was originally delayed when they discovered a power-supply needed to be swapped. However after scraping the Tev losses looked very good; all below 1 KHz.</p> 
 
<p>Now some things which are curious.  TevMon shows <em>warm</em> for MEAN LOSTP and MEAN AGIGI2.  Mean LOSTP is 497Hz and Mean AGIGI2 is -0.03.  The Mean AGIGI2 could be warm since it may not be reporting ???...that's the only explanation I can think for it to report a negative value.  But I do not understand why LOSTP is warm. We need to understand these two before we go into serious silicon data taking.</p> 
  
<!-- Author: Ankush -->
<!-- Comment: Tue Jun 13 00;22;54 comment by...Ankush -->
<p>Steve rang up the MCR and found out AGIGI2 is not working.  So NO SILICON until this is up and running!!</p>

<!-- Comment: Tue Jun 13 00;55;06 comment by...Ankush -->
<p>I restarted TevMon to see if that would fix the pink LOSTP.  However it is still pink...I do not understand why this is so...</p>


<!-- Date: Tue Jun 13 08:35:28 2006 -->
<pre>I was paged because new shift crew didn't know what to do about pink (warning) state of TevMon. It turns out that LOSTP and AGIGI2  are pink, they have the same funny values (LOSTP=533, AGIGI2=-0.03) as it was noticed earlier by Ankush. It also appeared that ACEs were not running the TevMon page (global page with all params), so they didn't know what was going on. I had to explain them that TevMon should be running all the time and they should pay attention what parameters are not green.   </pre>
<!-- Author: sasha -->


<!-- Date: Tue Jun 13 10:19:17 2006 -->
<h3>COT Primary Vertex Positions and Slopes</h3> 
I have compared the COT vertex positions and slopes of the current run with an old run from February. The results can be found in the  
<a href= 
'http://www-cdfonline.fnal.gov/cgi/elog/elog.pl?nb=2006&action=view&page=397&frame=2&anchor=09:18:31.896'> 
main e-log</a>.
<!-- Author: Ulrich -->


<!-- Date: Tue Jun 13 11:44:02 2006 -->
<h3>TevMon State</h3> 
After digging through some source code we discovered the reason why MEAN LOSTP is still pink in TevMon while the losses are reasonable (300-500 Hz). The reason is that the status for LOSTP changes to "Warning" if C:B0PLOS (sum of bunch-by-bunch losses) is below 20. We have checked that this is indeed the case now. We will ask Rick Tesarek about this reading. 
<p> 
In other notes, Randy (Thurman-Keup?) has started to work on calibrating AGIGI2, so hopefully, this warning will vanish soon.
<!-- Author: Ankush & Ulrich -->
<!-- Comment: Tue Jun 13 12;20;51 comment by...Ankush -->
<p>Just heard AGIGI2 has just been calibrated.  So it should be "good to go" for the next store...</p>


<!-- Comment: Tue Jun 13 22;00;34 comment by...Ankush -->
<p>In the end, Koji was the one responsible for the B0PLOS counter.  He went in to fix it.  He discovered a clock card they were using had goen bad.  He swapped in a new one and that fixed B0PLOS straight away.  It started giving sensible values and the pink LOSTP in TevMon went away.</p>
<!-- Date: Tue Jun 13 12:44:00 2006 -->
<h3>Cooling Trip</h3> 
Bill Noe and I were trying to understand how the PID loops work which regulate the electric bypass valves on the SVX and ISL chillers. In the course of doing so, we tripped SVX and L00 on overpressure in the supply line. The silicon is still off, and everything recovered fine.  
<!-- Author: Ulrich -->


<!-- Date: Tue Jun 13 12:51:56 2006 -->
<h4>PID Loops</h4> 
Bill and I are confused about the way the PID (proportional-integral-differential) loops for the chiller bypass valves work. The process variable is the supply pressure. To regulate this variable against a set point, an e-valve is opened/closed. This is done to have kind of a buffer between the pressure delivered by the chiller and the cooling system. 
<p> 
The SVX loop is current doing what we want, but we do not understand why. The current pressure is at 26 psi, and the set point is at 30 psi. To get the pressure up to the set point, the bypass should be closed, right? Wrong, the valve is open at 36%. 
The ISL loop has a set point of 31.1 psi and runs at 23-24 psi. The e-valve is fully closed all the time. Weird.
<!-- Author: Ulrich -->


<!-- Date: Tue Jun 13 12:55:51 2006 -->
<h3>Tev work done so far and plans for the next store</h3> 
 
<p>The Tev has done the following: 
 
<ul> 
<li>AGIGI2 has now been calibrated.  So it should be running for the next store.</li> 
<li>Tev have worked on abort timinig and position.</li> 
</ul> 
 
Both of these are nice to hear.</p> 
 
<p>For the end of this store, they want to do: 
 
 
<ul> 
<li>2 hours of separator scans</li> 
<li>check the A48 collimator position</li>  
</ul> 
 
 Then they plan to end the store via the "Big Red Abort Button".  If this drops the beam permit, then we should check our BLMs and see how clean it is.</p> 
 
<p>Then we should expect shot setup around 4-5pm.  Then Ulrich and I will have to decide if we are going to put silicon in for a few hours in the middle of the store.</p>  
<!-- Author: Ankush -->


<!-- Date: Tue Jun 13 12:57:19 2006 -->
<h4>Resin exchange</h4> 
The cryo techs have exchanged resin two weeks ago to bring back the conductivity of the coolant after the long shut down. The SVX conductivity came back very slowly to 13.4 μSiemens/cm, still to high. The ISL conductivity is still not within the range of the conductivity measuring device, so it shows 16 μSiemens/cm. Jim Humpert will change the resin once more this afternoon.
<!-- Author: Ulrich -->
<!-- Comment: Tue Jun 13 16;15;57 comment by...Jennifer :-) -->
<pre>All set. No trips, no problems.</pre>
<!-- Date: Tue Jun 13 13:49:05 2006 -->
<br><br><b>CCC status</b><br> 
<ul> 
<li> 0x3000: this is the most reliable CCC, had no problems 
this far, it is connected to the SVX SRC and working fine. 
<li> 0x7000: This was the one that  <a href= 
'/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=303&frame=2&anchor=19:01:01'> 
was not locking to RF</a>. Bill burned again the firmware and since then it is working fine, both at FCC and at tstsvx1. 0x7000 is in tstsvx1 and is being tested, so far it looks good.  
<li> 0x5000: still has the <a href= 
'/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=303&frame=2&anchor=19:01:01'> 
problem</a> that the delay is sometimes stuck at 0x10. This causes a GAP error (which is not always reflected in the from LEDs). This CCC has to be debugged further. The problem is that at FCC we could reproduce the error for a while, but then it went away, it can not be reproduced reliably at tstsvx1 either. 
</ul> 
While 
checking the CCC I found that one of the AMP cables is bad (I could see this because some clock signals were absent in the SRC MCLK LA pod, and by just moving a little the conector they were fine, changing the cable solved the problem (the old cable is labeled as bad). <br>
<!-- Author: Sebastian -->

<!-- Date: Tue Jun 13 15:39:13 2006 -->
Entered in Silicon database: <ul>
<li>Ladder: SB1W5L4 
<li>problem n: 11 
<li>Status: unfixable
<li>Type: DropReadOut_nonRX
<li>Action: Diagnosis_update
<li>entered by: mhartz 
<li>description is: Since we have given up on this BE kludge, we add all chips to the stuckChips.txt to SVXMon will ignore capid errors. 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B1W5&layer=L4">report</a></ul>
<!-- Author: Problem DB -->



<!-- Date: Tue Jun 13 15:44:44 2006 -->
<h3>More alphanumeric pager use...</h3> 
Now, sent to the alphanumeric pager are errors from the CCC, letting me (or Ulrich) know when SVX and ISL are not receiving consistent clock signals. Mark made it so that it gives me a message letting me know of the problem, and kindly instructing me to page Sebastian.  
<p> 
Sorry, Sebby.
<!-- Author: Jennifer :-) -->



<!-- Date: Tue Jun 13 17:18:16 2006 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-8727&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-8727  width='300' align='top'></a></td><td>Here's our FIFO plot from the "abort". We didn't see anything appreciable.</td></tr></table>
<!-- Author: Jennifer :-) -->
<!-- Comment: Tue Jun 13 18;05;57 comment by...Marcel -->
In a really clean abort, the line should be just flat ....
<!-- Comment: Tue Jun 13 19;22;38 comment by...Ulrich -->
Come on, we are talking about radiation levels around the integration threshold (2 mrad/s without bleed current, 8 mrad/s with bleed current). Around here, one ADC count corresponds to roughly 1 mrad/s.
<!-- Comment: Tue Jun 13 23;51;59 comment by...Marcel -->
It is not the dose, but it is an abort, our BLM's usually do not even latch after the abort. At least that was the case before the shutdown. And if the abort works, there should be really nothing, since the beam is kicked out at A0.

<!-- Comment: Wed Jun 14 09;03;19 comment by...Ulrich -->
The BLM FIFOs latched because MCR aborted the beam via the "Red Button" on purpuse (i.e. in order to use all the abort diagnostics, including our BLM FIFOs).
<!-- Date: Tue Jun 13 17:57:22 2006 -->
<h3>Cooling Down the Silicon</h3> 
In preparation for the second 36x36 store after the shutdown, we bring the SVX set point back to -10°C (from -6°C). We proceed in two steps, first going to -8°C, then to -10°C. Currently, the silicon is still OFF.  
<!-- Author: Ulrich -->
<!-- Comment: Tue Jun 13 17;59;39 comment by...Ulrich -->
As expected, all pressures go up with the lower temperature. The BHW1 pressure exceeds the iFix warning limit of 13.3 psi. Since there is plenty of flow, I reduce the valve opening from 80% to 75%, which brings the pressure down to 12.8 psi.


<!-- Comment: Tue Jun 13 18;06;42 comment by...Ulrich -->
Also the SVX chiller has some calibration issues: it is slightly colder than we want. Due to the lack of time to play around with temperatures, I decided to calibrate the issue away by just changing the BIAS setting for INPUT1 on the chiller controller. It is now at -1.5 (was -0.7 before.

<!-- Comment: Tue Jun 13 18;34;49 comment by...Ulrich -->
The calibration seems to be ok. The chiller is now at -10°C, both according to the controller and according to iFix.

<!-- Comment: Tue Jun 13 18;37;09 comment by...Ulrich -->
Since we are 4°C colder now, I have adjusted some limits:
<ul>
<li>The PLC hardware trip limit for the BH temperatures is now at +2°C (from +5°C). Note: this one was wrong when Ankush hit the crash button.</li>
<li>I have hit "Set A/W Limits" to update all limits in the system.</li>
</ul>


<!-- Date: Tue Jun 13 18:52:33 2006 -->
<h3>The Plan</h3> 
 
<p>The previous store was pretty much perfect.   
 
<ul> 
<li>The losses were low and similar to the values before the shudown</li> 
<li>The store was aborted with the "MCR red abort button" and the BLM losses were very,very small (...but they were non-zero).</li> 
</ul> 
 
Also the Tev have worked on the abort timing and position, conditioned separators several times and today checked the A48 collimator position.  So it would appear this time they have done much more preparation work.</p> 
 
<p>So if this next store is similar to the previous store we will put Silicon in 2 hours after shot setup. We will first put silicon to STANDBY (it is still OFF) and then put silicon to ON. 
Silicon will remain in for 3 hours and then be put back to STANDBY, not OFF.   From then on, silicon will remain at STANDBY.</p> 
 
<p>We will be in the control room for the whole period watching the fast time plotter.  Before we start powering the silicon, we will tell MCR the silicon is being powered up and NO tuning, adjustments, etc are to be made.  The beam must be stable.  The same must be true for CDF.  No more fiddling, adjusting any parts of the dectector, trigger, etc.</p> 
 
<p>If the beam for any reason does not look right, Silicon will be taken to STANDBY.</p> 
 
<p>If shot setup is delayed till after 8pm, we will postpone the Silicon inclusion until the following morning and start after the 8am meeting.  Also if CDF is not running stably after 10pm, we shall do the same.</p>  
<!-- Author: Ankush & Ulrich -->



<!-- Date: Tue Jun 13 21:49:43 2006 -->
<h3>Store 4760</h3> 
 
<p>This store appeared to come in OK. Proton and pbar transfers went in very smoothly. However the intial lumi was surprisingly low...it was only ~20e30.  This surprised us and the MCR.  Then they discovered the D17V vertical separator was switched with the wrong polarity !!! It turns out the separator never reached 0 Volts during the squeeze and so the polarity never flipped.  This was fixed and the beam has to be re-scrapped.  Then the lumi jumped up to ~50e30.</p> 
 
<p>Given the beam adjustments & rescraping, I do not feel too confident putting the Silicon in now.  So Ulrich and I will go home now and see how the stores pans out overnight.  If the store is still in, the losses remain static and no further adjustments are made, then Silicon will go in for its short 3 hour run.</p>
<!-- Author: Ankush -->



<!-- Date: Tue Jun 13 22:00:38 2006 -->
<h3>Warming up the Silicon</h3> 
 
This afternoon we have cooled down SVX to -10°C to prepare for the store. The detector was still OFF, because we wanted to wait into the store to decide if we put it to STANDBY. Shortly before data-taking, we got COT alarms. Morris identified them as <a href= 
'http://www-cdfonline.fnal.gov/cgi/elog/elog.pl?nb=2006&action=view&page=398&frame=2&anchor=21:13:36.314'> 
temperature problems</a>. As it turned out, things became too cold for the COT, the lowest temperature being below 60°F. When we realized that the store was not as smooth, we took SVX back to -8°C, and now that we have canceled our plans for tonight, it is back to -6°.
<!-- Author: Ulrich -->


<!-- Date: Tue Jun 13 22:04:06 2006 -->
<center><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-8728&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-8728' width='300'></a><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-8730&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-8730' width='300'></a></center>
<!-- Author: Ankush -->
<!-- Comment: Tue Jun 13 22;10;16 comment by...Ankush -->
<h3>ACNET Plots for Store 4759</h3>

<p>Here are the loss plots for store 4759.  The large losses at the start are from scraping.  The large losses at the end are from Tev studies where they did a separtor scan and checked the position of the A48 collimator.  During the normal store, B0PAGC increases in time. But the upper value is less than 3KHz and this feature was seen in plots before the shutdown, ever since the Tevatron changed its "tunes" to a new operating point.</p>

<p>The right hand plot shows the variation of AGIGI2 and its pedestal value AGIGPED.  Druing the store AGIGI2 started to increase and then became very big during the Tev end-of-store studies.   It was during these end-of-store studies that AGIGI2 was calibrated and this is seen in the shift of AGIGPED.</p>



<!-- Date: Tue Jun 13 22:05:50 2006 -->
<h3>TevMon and AGIGI2</h3> 
TevMon still has a problem with AGIGI2. We see this variable updating fine in ACNET (from the .CDF logger), but TevMon thinks it is not updating. Therefore, TevMon is in warning. We will mail Ray Culbertson about this problem.
<!-- Author: Ulrich -->
<!-- Comment: Tue Jun 13 23;58;21 comment by...Ankush -->
<p>Ray restarted the ACNET monitor log and now TevMon is no longer reporting any problems with AGIGI2 and it is updating nicely.</p>


<!-- Date: Wed Jun 14 00:58:46 2006 -->
I have the SRC pager working (722-7599), if there are SRC/clock problems please let me know.
<!-- Author: Sebastian -->


<!-- Date: Wed Jun 14 03:48:34 2006 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-8732&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-8732  width='300' align='top'></a></td><td><h4>Got paged about AGIGI2</h4> 
 
<p>I was paged as TevMon was alarming AGIGI2 is too high...and indeed it is.  It is currently around 5 and looking at the trend it may go higher.</p> 
 
<p>Now AGIGI2 was recalibrated earlier in the day so one may expect the absolute value to be different.  However, seeing such a postitive growth makes me worried.</p> 
 
<p>There does appear to be a small dip for recent values.  I look again in a few hours and see if it settles some more.   it looks like the battle with AGIGI2 has recommenced.</p></td></tr></table>
<!-- Author: Ankush -->
<!-- Comment: Wed Jun 14 07;41;25 comment by...Ulrich -->
Here are a couple of comments about AGIGI2 from the MCR log:
<pre>
05:37:07-   CDF silicon is off. They turned off due AGIGI2 level. Attempts to scrub the abort gap were not that successful. Reduced AGIGI2 from 7 to 5.5 before D0AHTL and LOSTPB started to increase. Paging Dean for other ideas.  - dln
-- Wed Jun 14 05:43:23 comment by...dln --  Operational note: The timing delay baseline for the TEL, T:L1DLY, probably changed after the shutdown. Previously it was commonly set around 173 rfc and the upper and lower limits for scrubbing were 190 rfc and 125 rfc. Now it is at 193 rfc so I ran the timing from 145 rfc to 225 rfc to get any affect. We should confirm this with Xiaolong.
-- Wed Jun 14 05:50:20 comment by...dln --  AGIGI2 only dropped to 5.5 on the scrubbing. Informed CDF that we could insert a collimator or rescrape. They have decided not to attempt to turn on the silicon until after their 0800 meeting. So we aren't going to risk the collimator move or the rescrape. Tev experts should consult with CDF this morning.
</pre>
<!-- Date: Wed Jun 14 07:20:18 2006 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-8733&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-8733  width='300' align='top'></a></td><td>COT beam positions for Store 4760. They are virtually unchanged compared to yesterday.</td></tr></table>
<!-- Author: Ulrich -->



<!-- Date: Wed Jun 14 08:38:32 2006 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-8734&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-8734  width='300' align='top'></a></td><td><h3>The rise and rise of AGIGI2</h3> 
 
<p>In the middle of the night, an attempt was made to reduce AGIGI2.  It did lower a little but started rising again at a steeper rate.</p></td></tr></table>
<!-- Author: Ankush -->



<!-- Date: Wed Jun 14 11:35:46 2006 -->
<h3>Cooling down again</h3> 
The abort gap has been cleaned up significantly by MCR, and everything is looking nice and stable right now. We decide to get our silicon data. As a first step, we cool down the detector to -10°C (via -8°C)
<!-- Author: Ulrich -->
<!-- Comment: Wed Jun 14 12;16;37 comment by...Ulrich -->
The set point is now at -10°C. I have hit "Set A/W Limits" and unignored all iFix alarms except the conductivity. We will have to wait for about 1/2 hour for everything to settle down.
<!-- Date: Wed Jun 14 11:53:52 2006 -->
<center><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-8735&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-8735' width='300'></a><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-8736&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-8736' width='300'></a></center>
<!-- Author: Ankush -->
<!-- Comment: Wed Jun 14 11;55;18 comment by...Ankush -->
<h3>Abort Gap Clean Up</h3>

<p>In the morning, the TeV experts were able to clean up the abort gap. Now AGIGI2 is down to ~0.5 and all other losses are low.  However B0PAGC is a little high at 6kHz but it is stable and it is well below our limits.</p>


<!-- Date: Wed Jun 14 12:05:57 2006 -->
<h3>The Plan</h3> 
 
<p>As the beam looks much cleaner now and is looking stable, we are going to put silicon in for 3 hours.  Ulrich has already started cooling down SVX to -10C.  When the detector is cold, we will bring SVX, ISL and L00 to STANDBY.  Then we shall wait for whole detector temperature to be completly stable. For this cool down we have already informed the COT folks.</p> 
 
<p>We have already done a Ghost Buster check.  It is working. We should also reset any IMON AVDD/DVDD pinkies we have been putting off.Stefano Torre will be here keeping an eye on SVT.</p> 
 
 
<p>We shall keep an eye on initial trigger rates and any IMON pinkies.  SVXMon will need to be running.</p> 
 
<p>At the first sign the the beam looks unstable, Silicon will immediately go to STANDBY.</p>
<!-- Author: Ankush & Ulrich -->
<!-- Comment: Wed Jun 14 12;23;01 comment by...Ankush -->
<table border=0><td><tr><td bgcolor=#e0e030><p>
CAEN 5V Enables are ON<br>  
All iFIX alarms are re-enabled<br>
Silicon is at STANDBY<br>
</p>
  

<p>We are back to normal operations mode. Do NOT turn silicon OFF, do NOT touch the 5V enables, do NOT disable alarms. All alarms are now real.</p></td></tr></td></table>

<!-- Comment: Wed Jun 14 13;26;12 comment by...Ankush & Ulrich -->
The silicon is biased now.


<!-- Date: Wed Jun 14 13:51:08 2006 -->
<h3>Tevatron Abort</h3> 
We were just running for a couple of minutes, when the Tevatron was aborted: 
<pre> 
13:46:14-   Tev abort, A0 coasting beam valve. Investigating. - djinn 
</pre> 
 
Seemed to be very clean for us. Working on post quench checkout now.
<!-- Author: Ulrich -->
<!-- Comment: Wed Jun 14 13;59;58 comment by...Ulrich -->
And the silicon is back to STANDBY, of course.

<!-- Comment: Wed Jun 14 14;01;00 comment by...Ulrich -->
As I said before, the abort was very clean for us. Please find the BLM plots in the 
<a href=
'http://www-cdfonline.fnal.gov/cgi/elog/elog.pl?nb=2006&action=view&page=400&frame=2&anchor=13:54:31.651'>
main e-log</a>.

<!-- Comment: Wed Jun 14 17;42;05 comment by...Ulrich -->
MCR has investigated the abort, and found out that the coasting beam valve was not the cause. Rather, somebody working there bumped into a loose cable. In Jim Morgan's words:
<pre>
14:51:51-   The store was lost due to a spurious A0 beam valve abort. It appears the combination of a loose cable and unauthorized work in the service building combined to cause the abort. CDF is making their 2.5 hour access, D0 is also taking advantage of the time. After the accesses are over, we will proceed with shot setup. - J. Morgan  
</pre>
<!-- Comment: Wed Jun 14 17;43;32 comment by...Ulrich -->
My initial guess was that the Fussballgott has caused the abort, just in time for the match. B.t.w.: <b>Germany 1 - Poland 0</b>.
<!-- Date: Wed Jun 14 14:12:59 2006 -->
Entered in Silicon database: <ul>
<li>Ladder: SB0W1L2 
<li>problem n: 1666 
<li>Status: needs_observation
<li>Type: AVDD
<li>Action: IMON_limits
<li>entered by: amitra 
<li>description is: <p>reduced limits after shutdown</p><table border=1>
<tr><th>IMON LIMITS</th><th>Old</th><th>New</th></tr>
<tr><td><b>Nominal</b></td><td>755.767</td><td>590</td></tr>
<tr><td><b>Lower</b></td><td>655.0</td><td>525</td></tr>
<tr><td><b>Upper</b></td><td>785</td><td>655</td></tr></table> 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B0W1&layer=L2">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Wed Jun 14 14:20:15 2006 -->
Entered in Silicon database: <ul>
<li>Ladder: SB2W9L1 
<li>problem n: 1667 
<li>Status: needs_observation
<li>Type: AVDD
<li>Action: IMON_limits
<li>entered by: amitra 
<li>description is: <p>After shutdown, the IMON limits had to be lowered.</p><table border=1>
<tr><th>IMON LIMITS</th><th>Old</th><th>New</th></tr>
<tr><td><b>Nominal</b></td><td>487.886</td><td>496</td></tr>
<tr><td><b>Lower</b></td><td>480.0</td><td>486</td></tr>
<tr><td><b>Upper</b></td><td>490</td><td>506</td></tr></table> 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B2W9&layer=L1">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Wed Jun 14 15:03:17 2006 -->
<p><font size=+1> D-mode Calibration Job Started </font>
<p><pre>
Job id            : 440
Calibration type  : standard
Run period tag    : Jun_2006
DPS-off run       : 218259
DPS-on run        : 218262
Requested by      : Ed
Main process id   : 13351
Comment           : after 1st run with Si
</pre>
<!-- Author: CDF silicon D-mode calibration job server v1.4 -->
<!-- Comment: Wed Jun 14 15;04;49 comment by...Ankush -->
<p>As the silicon is up and we have quiet time I requested a quiet time D-Mode Calibration.</p>


<!-- Date: Wed Jun 14 15:22:31 2006 -->
<h3>Restarted IMON.  Now running from b0dasvx03</h3> 
 
<p>IMON was running really slow.  You would click on a button and it would react with a few second delay.  So I decided to restart it.  So as we now have b0dasvx03 running scientific linux, I decided to log into that machine and run IMON off it.</p> 
 
<p>If IMON starts acting strangley, switch to running IMON on b0dasvx01 or b0dasvx02; the two Red-Hat machines.</p> 
<!-- Author: Ankush -->

<!-- Date: Wed Jun 14 15:26:41 2006 -->
Entered in Silicon database: <ul>
<li>Ladder: SB2W9L3 
<li>problem n: 1668 
<li>Status: needs_observation
<li>Type: AVDD
<li>Action: IMON_limits
<li>entered by: amitra 
<li>description is: <p>Moved the IMON limits down after the 2006 shutdown.</p><table border=1>
<tr><th>IMON LIMITS</th><th>Old</th><th>New</th></tr>
<tr><td><b>Nominal</b></td><td>821.626</td><td>760</td></tr>
<tr><td><b>Lower</b></td><td>815.0</td><td>720</td></tr>
<tr><td><b>Upper</b></td><td>855.0</td><td>800.0</td></tr></table> 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B2W9&layer=L3">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Wed Jun 14 15:34:44 2006 -->
Entered in Silicon database: <ul>
<li>Ladder: SB2W9L0 
<li>problem n: 1669 
<li>Status: needs_observation
<li>Type: DVDD
<li>Action: IMON_limits
<li>entered by: amitra 
<li>description is: <p>Moved IMON limits down after 2006 shutdown.</p><table border=1>
<tr><th>IMON LIMITS</th><th>Old</th><th>New</th></tr>
<tr><td><b>Nominal</b></td><td>78.2237</td><td>26</td></tr>
<tr><td><b>Lower</b></td><td>65.0</td><td>16</td></tr>
<tr><td><b>Upper</b></td><td>85</td><td>36</td></tr></table> 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B2W9&layer=L0">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Wed Jun 14 15:41:22 2006 -->
Entered in Silicon database: <ul>
<li>Ladder: SB2W9L4 
<li>problem n: 1670 
<li>Status: needs_work
<li>Type: DVDD
<li>Action: IMON_limits
<li>entered by: amitra 
<li>description is: <p>Moved IMON limits down after 2006 shutdown</p><table border=1>
<tr><th>IMON LIMITS</th><th>Old</th><th>New</th></tr>
<tr><td><b>Nominal</b></td><td>207.522</td><td>100.0</td></tr>
<tr><td><b>Lower</b></td><td>155.0</td><td>55.0</td></tr>
<tr><td><b>Upper</b></td><td>245.0</td><td>145.0</td></tr></table> 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B2W9&layer=L4">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Wed Jun 14 15:46:49 2006 -->
Entered in Silicon database: <ul>
<li>Ladder: IB0W0L0 
<li>problem n: 1671 
<li>Status: needs_observation
<li>Type: AVDD
<li>Action: IMON_limits
<li>entered by: amitra 
<li>description is: <p>After the 2006 shutdown, I raised the IMON limits.</p><table border=1>
<tr><th>IMON LIMITS</th><th>Old</th><th>New</th></tr>
<tr><td><b>Nominal</b></td><td>1142.5</td><td>1160</td></tr>
<tr><td><b>Lower</b></td><td>1105.0</td><td>1137.5</td></tr>
<tr><td><b>Upper</b></td><td>1150.0</td><td>1182.5</td></tr></table> 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=ISL&wedge=B0W0&layer=L0">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Wed Jun 14 15:51:18 2006 -->
Entered in Silicon database: <ul>
<li>Ladder: IB0W2L1 
<li>problem n: 1672 
<li>Status: needs_observation
<li>Type: DVDD
<li>Action: IMON_limits
<li>entered by: amitra 
<li>description is: <p>After the 2006 shutdown, the IMON limits were lowered</p><table border=1>
<tr><th>IMON LIMITS</th><th>Old</th><th>New</th></tr>
<tr><td><b>Nominal</b></td><td>268.488</td><td>245.0</td></tr>
<tr><td><b>Lower</b></td><td>270.0</td><td>145.0</td></tr>
<tr><td><b>Upper</b></td><td>370.0</td><td>345.0</td></tr></table> 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=ISL&wedge=B0W2&layer=L1">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Wed Jun 14 15:57:11 2006 -->
Entered in Silicon database: <ul>
<li>Ladder: IB4W0L0 
<li>problem n: 1673 
<li>Status: needs_observation
<li>Type: DVDD
<li>Action: IMON_limits
<li>entered by: amitra 
<li>description is: <p>After the 2006 shutdown, the IMON limits had to be adjusted.</p><table border=1>
<tr><th>IMON LIMITS</th><th>Old</th><th>New</th></tr>
<tr><td><b>Nominal</b></td><td>359,799</td><td>500.0</td></tr>
<tr><td><b>Lower</b></td><td>340.0</td><td>447.5</td></tr>
<tr><td><b>Upper</b></td><td>445.0</td><td>552.5</td></tr></table> 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=ISL&wedge=B4W0&layer=L0">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Wed Jun 14 16:05:10 2006 -->
Entered in Silicon database: <ul>
<li>Ladder: IB5W0L0 
<li>problem n: 1331 
<li>Status: needs_observation
<li>Type: AVDD
<li>Action: IMON_limits
<li>entered by: amitra 
<li>description is: <p>After the 2006 shutdown, the IMON limits were lowered.</p><table border=1>
<tr><th>IMON LIMITS</th><th>Old</th><th>New</th></tr>
<tr><td><b>Nominal</b></td><td>1122.55</td><td>1095.0</td></tr>
<tr><td><b>Lower</b></td><td>1115.0</td><td>1090</td></tr>
<tr><td><b>Upper</b></td><td>1125.0</td><td>1100</td></tr></table> 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=ISL&wedge=B5W0&layer=L0">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Wed Jun 14 16:11:59 2006 -->
Entered in Silicon database: <ul>
<li>Ladder: IB5W0L3 
<li>problem n: 1674 
<li>Status: needs_observation
<li>Type: AVDD
<li>Action: IMON_limits
<li>entered by: amitra 
<li>description is: <p>After the 2006 shutdown, the IMON limit were lowered.</p><table border=1>
<tr><th>IMON LIMITS</th><th>Old</th><th>New</th></tr>
<tr><td><b>Nominal</b></td><td>1178.31</td><td>1155.0</td></tr>
<tr><td><b>Lower</b></td><td>1170.0</td><td>1147.5</td></tr>
<tr><td><b>Upper</b></td><td>1185.0</td><td>1162.5</td></tr></table> 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=ISL&wedge=B5W0&layer=L3">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Wed Jun 14 16:16:49 2006 -->
Entered in Silicon database: <ul>
<li>Ladder: IB5W1L2 
<li>problem n: 1675 
<li>Status: needs_observation
<li>Type: DVDD
<li>Action: IMON_limits
<li>entered by: amitra 
<li>description is: <p>After the 2006 shutdown, the IMON limits were lowered.</p><table border=1>
<tr><th>IMON LIMITS</th><th>Old</th><th>New</th></tr>
<tr><td><b>Nominal</b></td><td>346.758</td><td>310.0</td></tr>
<tr><td><b>Lower</b></td><td>330.0</td><td>260.0</td></tr>
<tr><td><b>Upper</b></td><td>430.0</td><td>360.0</td></tr></table> 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=ISL&wedge=B5W1&layer=L2">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Wed Jun 14 16:59:15 2006 -->
Entered in Silicon database: <ul>
<li>Ladder: IB5W1L4 
<li>problem n: 1676 
<li>Status: needs_observation
<li>Type: DVDD
<li>Action: IMON_limits
<li>entered by: amitra 
<li>description is: <p>After the 2006 shutdown, the IMON limit was lowered</p><table border=1>
<tr><th>IMON LIMITS</th><th>Old</th><th>New</th></tr>
<tr><td><b>Nominal</b></td><td>322.315</td><td>285</td></tr>
<tr><td><b>Lower</b></td><td>300.0</td><td>235.0</td></tr>
<tr><td><b>Upper</b></td><td>395.0</td><td>315.0</td></tr></table> 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=ISL&wedge=B5W1&layer=L4">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Wed Jun 14 17:05:04 2006 -->
Entered in Silicon database: <ul>
<li>Ladder: SB0W8L4 
<li>problem n: 1677 
<li>Status: needs_observation
<li>Type: AVDD
<li>Action: IMON_limits
<li>entered by: amitra 
<li>description is: <p>After 2006 shutdown, the IMON limits were adjusted.</p><table border=1>
<tr><th>IMON LIMITS</th><th>Old</th><th>New</th></tr>
<tr><td><b>Nominal</b></td><td>1020</td><td>1030</td></tr>
<tr><td><b>Lower</b></td><td>1016</td><td>1026</td></tr>
<tr><td><b>Upper</b></td><td>1024</td><td>1034</td></tr></table> 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B0W8&layer=L4">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Wed Jun 14 17:09:08 2006 -->
Entered in Silicon database: <ul>
<li>Ladder: IB0W0L2 
<li>problem n: 1622 
<li>Status: needs_work
<li>Type: Unknown
<li>Action: Removed_hdwdb
<li>entered by: amitra 
<li>description is: <p>This ladder stopped returning data back in Jan 2006.  Many attempts were made to revive this ladder.  As I cannot think of any thing else to do for this ladder I am taking it out of the hardware database.</p> 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=ISL&wedge=B0W0&layer=L2">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Wed Jun 14 17:09:08 2006 -->
Entered in Silicon database: <ul>
<li>Ladder: IB0W0L2 
<li>problem n: 1622 
<li>Status: needs_work
<li>Type: Unknown
<li>Action: Removed_hdwdb
<li>entered by: amitra 
<li>description is: <p>This ladder stopped returning data back in Jan 2006.  Many attempts were made to revive this ladder.  As I cannot think of any thing else to do for this ladder I am taking it out of the hardware database.</p> 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=ISL&wedge=B0W0&layer=L2">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Wed Jun 14 17:23:56 2006 -->
Entered in Silicon database: <ul>
<li>Ladder: SB1W1All 
<li>problem n: 1678 
<li>Status: needs_observation
<li>Type: VDOIM
<li>Action: IMON_limits
<li>entered by: amitra 
<li>description is: <p>After the 2006 shutdown, the 2V Doim IMON limit was increased.</p><table border=1>
<tr><th>IMON LIMITS</th><th>Old</th><th>New</th></tr>
<tr><td><b>Nominal</b></td><td>1087.15</td><td>1115.0</td></tr>
<tr><td><b>Lower</b></td><td>1055.0</td><td>1090</td></tr>
<tr><td><b>Upper</b></td><td>1100.0</td><td>1140</td></tr></table> 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B1W1&layer=All">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Wed Jun 14 17:29:59 2006 -->
Entered in Silicon database: <ul>
<li>Ladder: SB1W1All 
<li>problem n: 1679 
<li>Status: needs_observation
<li>Type: VDOIM
<li>Action: IMON_limits
<li>entered by: amitra 
<li>description is: <p>After the 2006 shutdown, the IMON limits were increased.</p><table border=1>
<tr><th>IMON LIMITS</th><th>Old</th><th>New</th></tr>
<tr><td><b>Nominal</b></td><td>1937.03</td><td>1965.0</td></tr>
<tr><td><b>Lower</b></td><td>1925.0</td><td>1952.5</td></tr>
<tr><td><b>Upper</b></td><td>1950.0</td><td>1977.5</td></tr></table> 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B1W1&layer=All">report</a></ul>
<!-- Author: Problem DB -->



<!-- Date: Wed Jun 14 17:35:14 2006 -->
<h3>ISL teststand at FCC</h3> 
 
<p>Jeannine and I had a trip to FCC this afternoon. We tried to make the ISL 1/4 ladder working --- no success. We hooked up the SVX PS to the ISL JC. The ISL ladder was connected to channel 3 on PC, and we were using 8chip.isl in esevme17.crate file. We couldn't power up the ladder -- it was tripping. The next time, we'll try to reproduce what Corrine was doing, i.e. we'll gang together two ISL hybrids (ESE20 & ESE21) and try to make them work.</p>
<!-- Author: sasha/jeannine -->




<!-- Date: Wed Jun 14 17:43:55 2006 -->
<h3>Summary of afternoon work (14 June 06)</h3> 
 
<p>After the premature end of the Tev store, I asked the ACEs to carry out without-beam DMode calibration.  Then I did some work adjusting the IMON limit for the following ladders:   
 
<ul> 
<li>The following has AVDD adjusted: 
<ul><li> e012, e291, e293, f000, f500, f503, e084</li></ul> 
</li> 
 
<li>The following has DVDD adjusted: 
<ul><li> e290, e294, f021, f400, f512, f514</li></ul> 
</li> 
 
<li>The 2V DOIM limit for e11 was adjusted.</li> 
 
</ul> 
 
</p> 
 
<p>After a few weeks of running, we should check the IMON limits again.  If we need new limits, we should ask Dean to generate new ones.</p> 
 
<p>I also took f002 out of the Hardware Database.  This ladder stopped returning data in Jan '06. Many attempts to revive the ladder failed.  So I took it out of the HWDB.  If anyone has any clever ideas, they will be welcomed.</p> 
 
<p>While doing the IMON work, IMON became very slow. So I restated it but this time running off b0dasvx03.  This will allow us to test our Scientific Linux robustness.</p> 
 
  
<!-- Author: Ankush -->


<!-- Date: Wed Jun 14 19:07:41 2006 -->
<h3>Lammel strikes back !!!</h3> 
 
<p>During the previous store I tried to run the SVT spymon which failed to work.  Of course the perl wrapper was still pointing to the old web address.  I updated but SVTSpymon still failed...</p> 
 
<p>Ulrich suggested to check we didn't need to be authenticated.  So I fired up a browser and type the address for the original web page and it asks for a password....aghhh!!!!</p> 
 
<p>We have been Lammelled</p>
<!-- Author: Ankush -->
<!-- Comment: Wed Jun 14 19;12;02 comment by...Ankush -->
<p>..but all evil creatures must be destroyed.  Ulrich used wget inside the PERL wrapper and we are back in business.</p>

<!-- Date: Wed Jun 14 19:26:35 2006 -->
<p><font size=+1> D-mode Calibration Job Finished </font>
<p><pre>
This is a computer-generated silicon D-mode calibration status report.
Silicon D-mode calibration job 440 FAILED.

Job info
--------
Calibration type : standard
DPS-off run      : 218259
DPS-on run       : 218262
Requested by     : Ed
Submitted        : 2006-06-14 15:02:59
Completed        : 2006-06-14 19:26:16
Status           : FAILURE
Comment          : after 1st run with Si

Last processing stage reported : updating ped tables with fibkill channels
Failure diagnostics :
child process exited abnormally
</pre>
<!-- Author: D-mode script  -->
<!-- Comment: Thu Jun 15 11;23;57 comment by...Jason Nielsen -->
Restarted job from this point, and it finished fine.

<!-- Date: Wed Jun 14 19:51:10 2006 -->
<h3>Tally of ladders in/out since the shutdown</h3> 
 
<p>For documentation, here is a list of ladder put in/out the HWDB during the shutdown.</p> 
 
<ul> 
<li>Ladders in: e084, e0b2, e130, e404</li> 
<li>Ladders out: e244, f002</li> 
</ul> 
 
<p>In a month or two, we should have a look at e522.  This ladder has a history of coming and going.  So it may decide to come back.</p>
<!-- Author: Ankush -->


<!-- Date: Wed Jun 14 20:51:51 2006 -->
<h3>Tevatron Quench</h3> 
The Tevatron quenched again, this time during acceleration. The aces did a post-quench checkout (BLM FIFOs  
<a href= 
'http://www-cdfonline.fnal.gov/cgi/elog/elog.pl?nb=2006&action=view&page=401&frame=2&anchor=20:28:12.551'> 
here</a>). Everything was clean for us. 
 
Here is the current hypothesis why this happened from the Tevatron e-log: 
<pre> 
 Wed Jun 14 20:39:53 comment by...rm, bh --  Recall this is the first store in which we turned off the TEL-1 at 150 GeV since we wanted a longer electron pulse for abort gap cleaning during HEP. Without the TEL @ 150 GeV, the accumulated DC beam likely fell out and quenched us @ B26 - one of those high dispersion areas that got us in the past. 
-- Wed Jun 14 20:44:08 comment by...rm, bh --  We could 1) change the TEL-1 pulsing scheme back to the shorter pulse that can fit between the protons and pbars @ 150; 2) start making orbit bumps. Option 1) is probably the best choice since if we bump at B26, we'll just push that DC beam loss somewhere else around the ring and we'll be chasing it for a few shots. (We've suffered through that before.)   
</pre>
<!-- Author: Ankush & Ulrich -->


<!-- Date: Wed Jun 14 20:52:52 2006 -->
<h3>Possible problem with f54/f55</h3> 
 
<p>For the short 10 minute run we had in the morning, DS has already processed the data and the results show CAP-ID errors for all ladders in wedges f54/f55  ==> Maybe a FIB problem?</p> 
 
<p>However we now have a small bit of quiet time.  We ran f54/f55 quickly and we got errors for f551 and f553.  f551 has a known CAP-ID problem.  However we are now getting 00 Sequence errors for f553...this may be temperature related ?  Unfortunatly we did not get time to run the ladder in NN mode.</p> 
 
<p>So let's wait for the next store, try to put the silicon in for a few hours and see if these errors are persistant.</p>
<!-- Author: Ankush & Ulrich -->

<!-- Date: Wed Jun 14 21:05:29 2006 -->
Entered in Silicon database: <ul>
<li>Ladder: IB5W1L3 
<li>problem n: 1680 
<li>Status: needs_observation
<li>Type: AVDD
<li>Action: IMON_limits
<li>entered by: husemann 
<li>description is: Pinkie in AVDD after 2006 shutdown. Bumping up IMON limits.<table border=1>
<tr><th>IMON LIMITS</th><th>Old</th><th>New</th></tr>
<tr><td><b>Nominal</b></td><td>1103.01</td><td>1120</td></tr>
<tr><td><b>Lower</b></td><td>1065.0</td><td>1100</td></tr>
<tr><td><b>Upper</b></td><td>1105.0</td><td>1140</td></tr></table> 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=ISL&wedge=B5W1&layer=L3">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Wed Jun 14 21:09:05 2006 -->
Entered in Silicon database: <ul>
<li>Ladder: SB4W6All 
<li>problem n: 1681 
<li>Status: needs_observation
<li>Type: VDOIM
<li>Action: IMON_limits
<li>entered by: husemann 
<li>description is: DOIM currents went slightly down after shutdown. Adjusted limits.<table border=1>
<tr><th>IMON LIMITS</th><th>Old</th><th>New</th></tr>
<tr><td><b>Nominal</b></td><td>1128.01</td><td>1000.0</td></tr>
<tr><td><b>Lower</b></td><td>1050.0</td><td>960</td></tr>
<tr><td><b>Upper</b></td><td>1135.0</td><td>1040</td></tr></table> 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B4W6&layer=All">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Wed Jun 14 21:10:02 2006 -->
Entered in Silicon database: <ul>
<li>Ladder: SB4W6All 
<li>problem n: 1681 
<li>Status: needs_observation
<li>Type: VDOIM
<li>Action: Diagnosis_update
<li>entered by: husemann 
<li>description is: Previous entry is for 2V DOIM voltage. 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B4W6&layer=All">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Wed Jun 14 21:13:13 2006 -->
Entered in Silicon database: <ul>
<li>Ladder: SB4W6All 
<li>problem n: 1682 
<li>Status: needs_observation
<li>Type: VDOIM
<li>Action: IMON_limits
<li>entered by: husemann 
<li>description is: 5V DOIM current went slightly down after the 2006 shutdown. Adjusting limits.<table border=1>
<tr><th>IMON LIMITS</th><th>Old</th><th>New</th></tr>
<tr><td><b>Nominal</b></td><td>1963.9</td><td>1830.0</td></tr>
<tr><td><b>Lower</b></td><td>1885.0</td><td>1790.0</td></tr>
<tr><td><b>Upper</b></td><td>1970.0</td><td>1870.0</td></tr></table> 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B4W6&layer=All">report</a></ul>
<!-- Author: Problem DB -->



<!-- Date: Wed Jun 14 23:14:56 2006 -->
<h3>The Plan from Jim Morgan</h3> 
 
<pre> 
The Collider Plan: Tevatron studiers will do a series of  
aperture scans after the Tevatron is turned back on. Send pbars  
to the Recycler when the stack is in the 60-80E10 range. The  
Crew Chief should coordinate with Tev studies and maximize the  
stash size. Shot setup would follow the studies, protons  
240-260E9 per bunch in the Tevatron at 150 GeV unless specified  
otherwise by the Machine Coordinator. 
</pre> 
 
<p>The aperture scan makes me a little worried as the Silicon is now at STANDBY.</p>
<!-- Author: Ankush -->


<!-- Date: Thu Jun 15 09:15:39 2006 -->
SVXIICON rebooted.
<!-- Author: Ulrich -->


<!-- Date: Thu Jun 15 09:47:44 2006 -->
<h2>The Supplies are in!</h2> 
Yesterday our first two shipments of supplies from CAEN came back (2 forward ISL supplies, 2 L00 supplies).  Hank did a quick check on them, the crate sees them all, and I picked them up this morning.  Now I'll do more detailed burn-in tests to make sure all the problems are really fixed (and we didn't develop any new ones going through customs).  IF these 4 supplies are all ok, then we're sitting pretty good as far as power supplies go - we already have 2 SVX and 1 L00 spare.<br>
<!-- Author: Jen -->



<!-- Date: Thu Jun 15 13:07:37 2006 -->
<h3>CCC ready to HALT data taking if no RF</h3> 
 
With Bill and Mousumi we have a version of FER that will pick the interrupt from the CCC is lock to RF is lost and will go to HALT and give a warning (asking to page Silicon). We tested this yesterday in the teststand and everything worked fine. Other  
errors (different from !RF) are ignored and cleared for now). 
I have modified the CCC interface module, so that it does not conflict with the ISR used by FER.  
<br> 
We have to give Bill the OK so that he changes to FER version and we soft reboot b0svx02 and 06 to pick the changes. The idea is to do this during the next quiet time. 
<br>  
<!-- Author: Sebastian -->


<!-- Date: Thu Jun 15 13:09:34 2006 -->
A new radiation entry at the entry in the <a href= 
'http://www-cdfonline.fnal.gov/cgi/elog/elog.pl?nb=2006&action=view&page=403&frame=2&anchor=13:06:16.148'> 
Main e-log</a>
<!-- Author: Jennifer :-) -->


<!-- Date: Thu Jun 15 13:24:11 2006 -->
<h3>Store 4772</h3> 
Store #4772 is in with an initial luminosity of 68e30. Currently, all TevMon parameters look nice and stable. The plan for this store is: 
<ul> 
<li>Watch the beam conditions for the first hour into the store.</li> 
<li>Go in after an hour, beam conditions allowing, and run for about 3 hours.</li> 
<li>Run with L3 filters on Scientific Linux.</li> 
</ul>
<!-- Author: Ankush & Ulrich -->


<!-- Date: Thu Jun 15 14:36:34 2006 -->
<h3>Taking data with Silicon</h3> 
After watching the store for 3/4 of an hour, Ankush and I decided that it is stable enough to include the silicon. We ramped the silicon without problems and started a first run. 
<p> 
After a couple of minutes, b0svx02 got stuck and would not go to HALT. I called Marcel to the rescue. We could vxlogin to the crate, and all relevant processes were running. However, the crate lost contact to run control. Marcel rebooted the crate and asked the shift crew to start a new run. The crate came back fine. Note: Steve Nahn and Marcel have disabled the possibility to reset the crate from run control, so Marcel did the reboot "by hand" via vxlogin. 
<p> 
The new run is now proceeding fine. After a couple of pre-scale changes, the L1A rate is now at 24 kHz.
<!-- Author: Ulrich with the help of Marcel -->
<!-- Comment: Thu Jun 15 14;37;32 comment by...Ulrich -->
Shortly after the new run came on, SVXMon discovered a lot of stuck cell IDs. The Ace did an HRR, and they came back fine.

<!-- Comment: Thu Jun 15 16;24;49 comment by...Marcel -->
Some comments from one of the old guys:<br>
<ul>
<li>If a b0svxXX crate gets stuck (it turns yellow/red) in RunControl, you have to end the Run and start from scratch. These crates cannot be sherperded, rebooted or send the transition command again. This is a feature originating from Steve N. to avoid people muppeting around with these crates. Keep in mind, these crates host the SRc's, the Ghostbuster and now the CCC. You don't want Aces to monkey around with these.
</li>
<li>
In this case, the crate was fine, but it did not recieve any RunControl commands anymore. So doing a reboot of the crate CPU is the way to go and the fastest way to get things back
</li>

</ul>


<!-- Date: Thu Jun 15 17:04:03 2006 -->
<h3>Silicon status for store 4772</h3> 
 
<p> 
<li>IMon is very slow on b0dasvx03.</li> 
<li>a link to SpyMon is broken.</li> 
</p> 
<p> 
Yellow in SVXMON: 
<ul><li>e124--- this ladder had problems before, but it fixed itself on 01/02/06. So, it looks like it decided to unfix itself now. One needs to check this ladder during quiet time.</li></ul> 
<ul><li>e564---no data from z-side; it has known bit7 low problem; it also had 99% of "no first chip" and "drop readout" in recent runs (caused by bit7 problem).</li></ul> 
<ul><li>e154--- we gave up on this ladder. One should put it in SVXMON_IGNORE at the end of this run or before next store. </li></ul> 
</p>  
<!-- Author: sasha -->
<!-- Comment: Thu Jun 15 20;08;20 comment by...Ankush -->
<p>I've added "needs work" threads e123 to e564.  So now they have "checks disabled" in SVXMon.  e154 is marked as unfixable so I thought SVXMon would not check it.  But it still does.  So I added the "SVXMon Ignore" status to the problem DB.  Now all these ladders do not appear yellow in SVXMon.</p>

<p>But as soon as the BitReporter is updated we should check these ladders.</p>
<!-- Date: Thu Jun 15 19:43:23 2006 -->
Entered in Silicon database: <ul>
<li>Ladder: SB1W2L4 
<li>problem n: 1683 
<li>Status: needs_work
<li>Type: Unknown
<li>Action: Monitoring
<li>entered by: amitra 
<li>description is: <p>After the first long run of Silicon after the shutdown, this ladder is not returning any data according to SVXMon.  This ladder needs to be investigated.</p> 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B1W2&layer=L4">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Thu Jun 15 19:43:37 2006 -->
Entered in Silicon database: <ul>
<li>Ladder: SB1W2L4 
<li>problem n: 1684 
<li>Status: needs_work
<li>Type: Unknown
<li>Action: Monitoring
<li>entered by: amitra 
<li>description is: <p>After the first long run of Silicon after the shutdown, this ladder is not returning any data according to SVXMon.  This ladder needs to be investigated.</p> 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B1W2&layer=L4">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Thu Jun 15 19:46:10 2006 -->
Entered in Silicon database: <ul>
<li>Ladder: SB5W6L4 
<li>problem n: 345 
<li>Status: needs_work
<li>Type: Unknown
<li>Action: Monitoring
<li>entered by: amitra 
<li>description is: <p>After the first long run after the shutdown, this ladder is not returning data according to SVXMon.  This ladder needs to be investigated.</p> 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B5W6&layer=L4">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Thu Jun 15 19:47:20 2006 -->
Entered in Silicon database: <ul>
<li>Ladder: SB1W5L4 
<li>problem n: 11 
<li>Status: svxmon_ignore
<li>Type: DropReadOut_nonRX
<li>Action: Diagnosis_update
<li>entered by: amitra 
<li>description is: <p>This ladder has been declared unfixable according but SVXMon is still checking it.  Now adding the SVXMon ignore to mask it in SVXMon.</p> 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B1W5&layer=L4">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Thu Jun 15 20:06:48 2006 -->
Entered in Silicon database: <ul>
<li>Ladder: SB0W1L2 
<li>problem n: 1666 
<li>Status: needs_observation
<li>Type: AVDD
<li>Action: IMON_limits
<li>entered by: husemann 
<li>description is: And bumped up AVDD limits again by around 200. Apparently, there are chips coming and going in this ladder.<table border=1>
<tr><th>IMON LIMITS</th><th>Old</th><th>New</th></tr>
<tr><td><b>Nominal</b></td><td>755.767</td><td>750.0</td></tr>
<tr><td><b>Lower</b></td><td>525.0</td><td>690.0</td></tr>
<tr><td><b>Upper</b></td><td>655.0</td><td>810.0</td></tr></table> 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B0W1&layer=L2">report</a></ul>
<!-- Author: Problem DB -->



<!-- Date: Thu Jun 15 20:10:57 2006 -->
Entered in Silicon database: <ul>
<li>Ladder: SB0W8L4 
<li>problem n: 1677 
<li>Status: needs_observation
<li>Type: AVDD
<li>Action: IMON_limits
<li>entered by: husemann 
<li>description is: ... and adjusted back to the old values.<table border=1>
<tr><th>IMON LIMITS</th><th>Old</th><th>New</th></tr>
<tr><td><b>Nominal</b></td><td>1030.0</td><td>1020.0</td></tr>
<tr><td><b>Lower</b></td><td>1026.0</td><td>1016.0</td></tr>
<tr><td><b>Upper</b></td><td>1034.0</td><td>1024.0</td></tr></table> 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B0W8&layer=L4">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Thu Jun 15 20:13:01 2006 -->
Entered in Silicon database: <ul>
<li>Ladder: SB2W9L2 
<li>problem n: 1685 
<li>Status: needs_observation
<li>Type: AVDD
<li>Action: IMON_limits
<li>entered by: husemann 
<li>description is: Slightly changed AVDD current limit after 2006 shutdown.<table border=1>
<tr><th>IMON LIMITS</th><th>Old</th><th>New</th></tr>
<tr><td><b>Nominal</b></td><td>805.294</td><td>790.0</td></tr>
<tr><td><b>Lower</b></td><td>800.0</td><td>775.0</td></tr>
<tr><td><b>Upper</b></td><td>830.0</td><td>805.0</td></tr></table> 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B2W9&layer=L2">report</a></ul>
<!-- Author: Problem DB -->



<!-- Date: Thu Jun 15 20:21:07 2006 -->
<h3>HRR to fix e2b3</h3> 
 
<p>While going over the yellow ladders I noticed e2b3 went yellow.  A quick HRR fixed it.</p>
<!-- Author: Ankush -->


<!-- Date: Thu Jun 15 20:24:56 2006 -->
<h3>Fighting Pinkies: Part II</h3> 
We have the silicion biased for more than 6 hours now - time to re-visit a couple of AVDD pinkies: 
<ul> 
<li>e012: AVDD limit was adjusted to a lower value yesterday, back to old value today (a couple of chips coming and going?)</li> 
<li>e084: AVDD current went slightly up yesterday, came down by the same amount today.</li> 
<li>e292: AVDD dropped by 30 - this is new. 
</ul> 
All the remaining bias pinkies are in Micron ladders. The symptoms in all of them are very similar. They behaved stably before the shutdown, and now they jump all over the place. There is still hope that they come back to normal after being biased for a couple of days. Therefore, the bias currents for these ladders have been put to ignore for the time being: 
<ul> 
<li>e1a4</li> 
<li>e3b2</li> 
<li>e564</li> 
</ul> 
 
I will insert a typical plot of the bias current over time later.  
<!-- Author: Ulrich -->


<!-- Date: Thu Jun 15 20:25:53 2006 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-8737&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-8737  width='300' align='top'></a></td><td>Example for current bias current pinkie: e564.</td></tr></table>
<!-- Author: Ulrich -->


<!-- Date: Thu Jun 15 21:53:55 2006 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-8738&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-8738  width='300' align='top'></a></td><td><h3>Consistent L2A without L1A SRC error</h3> 
 
<p>During this run there was a L2A without L1A SRC error.  After an HRR it reappeared.  A new run was started but the error reappeared.  Silicon was taken out of the run and then a COLDSTART was done.  Again the same error.  But if you look at the LA plot, it looks like the CLOCK and L1A, L1D and L2A are fine.  So I do not understand this error.</p></td></tr></table>
<!-- Author: Ankush -->
<!-- Comment: Thu Jun 15 22;18;17 comment by...Sebastian -->
So, the CCC lost lock to RF, the LA did not trigger (did it? at least no page was recieved, right?) and since the new FER is not in place we did not get a warning. The question is why we lost lock. Could have been a real glitch, which with no CCC could have meant a trip of SVX, or someting bogus in the CCC (but this is the first time the CC looses lock afaik). 

<!-- Comment: Thu Jun 15 22;37;47 comment by...Unreliable Lady in Pink :-( -->
<pre>Sorry Guys, I'm a big jerk... I had it with me, but forgot to un-silence it after the lecture this afternoon!! :-(</pre>

<!-- Comment: Thu Jun 15 22;54;47 comment by...Ankush -->
<p>I think particular page was sent by me by accident.  So this was not a real CLK sync problem.  But it was certainly a good test of the paging system.</p>


<!-- Comment: Thu Jun 15 22;58;18 comment by...Ankush -->
<p>After Sebastian cleared the CCC errors COLDSTART ran without L2A without L1A errors.  We then put silicon back in and ran AAA_CURRENT and we have been running for about an hour with no further SRC errors.</p>
<!-- Date: Thu Jun 15 22:56:56 2006 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-8739&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-8739  width='300' align='top'></a></td><td><h3>The relentless rise of AGIGI2</h3> 
 
<p>In red is the history of AGIGI2 over the last few hours.  You can see it rise and rise monotonically with time.  By midnight it will probably hit 5.0 and TevMon will start complaining.  So for the time being Ulrich and I will take Silicon out and so it will not run overnight.</p></td></tr></table>
<!-- Author: Ankush -->
<!-- Comment: Fri Jun 16 10;13;48 comment by...Ulrich -->
And here is the experts working on the problem (from Tevatron e-log):
<pre>
-- Fri Jun 16 09:35:21 comment by...m.m --  Knobbed T:L1DLY to lower AGIGI2 rate. Started at about 9, got to about 4.8 but it bounced back to 6 quickly. Got greedy and whacked the beam with TEL, taking a nibble out of luminosity.
</pre>
<!-- Date: Fri Jun 16 10:12:56 2006 -->
<h3>Unbiased Ladders</h3> 
Yesterday I had a look at the bias currents in IMON. After eliminating most pinkies (and giving three Micron ladders a little more time), we are left with four ladders which show zero bias current: 
<ul> 
<li><b>e0b1</b>: re-included during PDB review, known to show no physics before, ADCMON: only noise</li> 
<li><b>e130</b>: re-included during PDB review, known to show no physics before, ADCMON: only noise</li> 
<li><b>f223</b>: known to show very small bias current, ADCMON spectrum ok.</li> 
<li><b>f411</b>: known to show very small bias current, ADCMON spectrum ok.</li> 
</ul> 
We will probably have to exclude the bad SVX ladders again.
<!-- Author: Ulrich -->



<!-- Date: Fri Jun 16 11:23:45 2006 -->
<h3>D0 2 shift access: coming soon...</h3> 
 
<p>D0 have requested a 2 shift access to address a noise problem in their calorimeter.  Apparently it's related to their muon system. It is most likely to occur during a week day.</p> 
 
<p>Given we potentially have a long access, we should come up with a plan to use this long access & quiet time. Things which come to mind are: 
 
<ul> 
<li>List of ladders which have now stopped working</i> 
<ul> 
<li>Do we just need to adjust chip settings?</li> 
<li>Do we need to do fibre swaps,etc in the collision hall</li> 
</ul> 
<li>The BUSY TO with COLDSTART has reappeared. This should be reinvestigated</li> 
<li>Remeasure the light levels of the permananent LL system in the collision hall.</li> 
</ul> 
 
</p> 
 
<p>Please add any extra items which need to be done.</p>
<!-- Author: Ankush -->


<!-- Date: Fri Jun 16 12:15:03 2006 -->
<h3>AGIGI2 successfully reduced - starting to take silicon data</h3> 
MCR has manage to reduce AGIGI2 from around 5.0 to 3.2. The SciCo called them, and they told them they are done with the tuning and expect AGIGI2 to be stable until the TeV studies (scheduled for 15:00). All other TevMon variables look fine. Now we are waiting for the aces to start a new run with silicon.
<!-- Author: Ulrich -->


<!-- Date: Fri Jun 16 12:49:55 2006 -->
<center><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-8740&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-8741' ></a><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-8742&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-8743' ></a></center>
<!-- Author: Ankush -->
<!-- Comment: Fri Jun 16 12;53;16 comment by...Ankush -->
<h3>Store 4772: Run # 218424</h3>

<p>At last SVTSPYMon.  But something does not look right.  SVTSPYMon shows wedges 10,11 on the first plot.  On the second plot , 5<phi<6 is empty.  I don't this is real as SVXMon shows all ladders in those wedges are OK.  So this may be a software problem or SVT is not seeing those wedges.</p>

<p>We will let Stefano Torre know about this.</p>

<!-- Comment: Fri Jun 16 13;20;06 comment by...Ankush -->
<p>Stefano and Alberto are here.  This is a real SVT problem.  A card in one of their crates needed a reboot.  SVT is now receiving data in all wedges.  But Silicon is OK.</p>


<!-- Date: Fri Jun 16 13:48:36 2006 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-8744&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-8744  width='300' align='top'></a></td><td><h3>SVTSPYMon Store 4772:   Run # 218426</h3> 
 
<p>After the SVT boys fixed the problem, SVTSPYMon looks much better now.</p></td></tr></table>
<!-- Author: Ankush -->
<!-- Comment: Fri Jun 16 13;56;00 comment by...Ankush -->
<p>...and SVXMon looks OK.</p>


<!-- Date: Fri Jun 16 14:22:15 2006 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-8745&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-8746  width='300' align='top'></a></td><td><h3>e012: Went PINK</h3> 
 
<p>There was a large drop in AVDD for this ladder.  A quick HRR and the current went back to normal.</p></td></tr></table>
<!-- Author: Ankush -->
<!-- Comment: Fri Jun 16 14;27;01 comment by...Ulrich -->
This ladder had a history of AVDD currents jumping up and down after the shutdown. We have adjusted the IMON limits to the upper state, such that we can spot the jump down and correct it via HRR.
<!-- Date: Fri Jun 16 14:25:23 2006 -->
<h3>3 Bias Cells set to ignore</h3> 
 
<p>Ulrich found 3 bias PINKIES which have some history of jumping around after a shutdown.  So while we wait for the currents to settle, I have set them to ignore in IMON.  The ladders are: e1a4, e3b2, and e564.</p>
<!-- Author: Ankush -->



<!-- Date: Fri Jun 16 15:03:09 2006 -->
<h3>Interesting note about AGIGI2 from the Tev elog</h3> 
 
<p>Over the past few stores AGIGI2 has been growing monotonically and required one the Tev experts to fix it.  From reading this entry from the Tev elog, they are also keeping an eye on AGIGI2.</p> 
 
<pre> 
Click here to make a comment, Email or link this entry Fri Jun 16 14:54:34-   Comments about Abort Gap Losses (T:AGIGI2): 
 
Past couple of stores have had problems with maintaining T:AGIGI2 below 7 E9. It appears there is more information about what can effect these values so those who have to reduce this value can have something to tune. the TEL timing T:L1DLY has been scanned from 146 to 226 with its nominal around 193. It should not be scanned below 150 because it is good probablity that the pbar bunches around the gaps will be clipped. A value of around 150 seem to be a good place to effect AGIGI2. Also the vertical tune plays into this equation. We have noticed that keeping the vertical tune around .583 will also help decreases these losses. The T:TFPMON wants to adjust the tunes through a store in order to keep the pbar tunes constant. If these changes make AGIGI2 grow rapidliy we should suspend the tune changes. Finally, the vertical position of the collimators should have some effect on AGIGI2. The D173 vertical collimator could be placed closer to the beam using C10 MANUAL PAGE with a step size of 1mil into the beam. Plot the BLM T:LD1733 and do not let it grow to a value bigger than 2.5V. 
 
Plans for keeping AGIGI2 over Weekend: 
 
1) Monitor T:AGIGI2 and if it is on the rise and starts exceding 3E9 a scan of the TEL timing using T:L1DLY can be done from 150 to 200. 
2)The vertical tune can also be used to help decrease these losses. Most likely it will want to decrease the vert tune. 
3) Finally moving D173 vert collimator closer may help. 
</pre> 
 
<p>If we spot AGIGI2 growing, one could also look at some of the ACNET variables quoted above.</p>
<!-- Author: Ankush -->

<!-- Date: Fri Jun 16 15:14:56 2006 -->
Entered in Silicon database: <ul>
<li>Ladder: SB0W8L4 
<li>problem n: 1677 
<li>Status: needs_observation
<li>Type: AVDD
<li>Action: IMON_limits
<li>entered by: husemann 
<li>description is: The range of limits turned out to be a little too tight. Bumping up the upper limit to increase the range from 8 μA to 18 μA.<table border=1>
<tr><th>IMON LIMITS</th><th>Old</th><th>New</th></tr>
<tr><td><b>Nominal</b></td><td>1020</td><td>1020</td></tr>
<tr><td><b>Lower</b></td><td>1016</td><td>1016</td></tr>
<tr><td><b>Upper</b></td><td>1024</td><td>1034</td></tr></table> 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B0W8&layer=L4">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Fri Jun 16 16:21:08 2006 -->
Entered in Silicon database: <ul>
<li>Ladder: IB0W0L0 
<li>problem n: 1019 
<li>Status: needs_observation
<li>Type: Chip_bit_error
<li>Action: Diagnosis_update
<li>entered by: sasha 
<li>description is: No problems in recent data runs. Need to continue observations for one more week. 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=ISL&wedge=B0W0&layer=L0">report</a></ul>
<!-- Author: Problem DB -->



<!-- Date: Fri Jun 16 18:17:03 2006 -->
<h3>Permananent Light Level Measurements: 1st repeat</h3> 
 
<p>During the quiet time, Ulrich and I went to the first floor while Sasha turned on e2b2.  Here are the results</p> 
 
<table border="1"> 
<tr><td>Bit</td><td>Measurement 1 (8 June 06) (μW)</td><td>Measurement 2 (16 June 06) (μW)</td></tr> 
<tr> <td> OBDV </td> <td> 240 </td> <td> 276  </td> </tr> 
<tr> <td> 0    </td> <td> 340 </td> <td> 352 </td> </tr> 
<tr> <td> 1    </td> <td> 470 </td> <td> 468 </td> </tr> 
<tr> <td> 2    </td> <td> 390 </td> <td> 404 </td> </tr> 
<tr> <td> 3    </td> <td> 450 </td> <td> 456 </td> </tr> 
<tr> <td> 4    </td> <td> 420 </td> <td> 420 </td> </tr> 
<tr> <td> 5    </td> <td> 380 </td> <td> 392 </td> </tr> 
<tr> <td> 6    </td> <td>  53 </td> <td>  48 </td> </tr> 
<tr> <td> 7    </td> <td> 448 </td> <td> 440 </td> </tr> 
</table> 
 
<p>So the two measurements aren't exactly the same to 3 digits but they are certainly comparable.  A few more repeat measurements to get some confidence in the repeatability and then we can do this every month.</p> 
 
<p>One more thing to try again is to do another repeat measurement of the light levels in the collision hall.</p>
<!-- Author: Ankush -->


<!-- Date: Fri Jun 16 18:33:51 2006 -->
<h3>SVTSPYMon Edited and Updated</h3> 
 
<p>A few edits to SVTSPYMon had to be made to cope with the change of the online web addresses and the change in the order of grpahs in the original SVTSPYMon PostScript File.</p> 
 
<p>So I renamed the original SVTSPYMon perl script as svtspymon_old.pl.  I then modified a version of the original one to  implement the changes mentioned in the previous paragraph.  If you have any problems with SVTSPYMon, let me know.</p>
<!-- Author: Ankush -->

<!-- Date: Fri Jun 16 18:44:14 2006 -->
Entered in Silicon database: <ul>
<li>Ladder: SB0W8L1 
<li>problem n: 1637 
<li>Status: needs_observation
<li>Type: Chip_bit_error
<li>Action: Diagnosis_update
<li>entered by: jwagner 
<li>description is: There are no errors in data and in SVXDAQ we (Sasha and I) saw in NN and RA 00_sequence errors at very low rate (10/1000). If there are no errors in data for one more week, we can declare it as fixed. 
<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: Fri Jun 16 18:58:46 2006 -->
Entered in Silicon database: <ul>
<li>Ladder: SB0W8L4 
<li>problem n: 1638 
<li>Status: needs_work
<li>Type: Chip_capid
<li>Action: Diagnosis_update
<li>entered by: jwagner 
<li>description is: In the recent data 100% errors occur (cap_id a6, old AVDD2 problem).We get no physics data from chip 10. Before the SVXDAQ test, this ladder triped at DVDD2 overcurrent. However this ladder behaves well in SVXDAQ (RA and NN mode). The settings of SVXDAQ and in the real data taking are the same. The ISEL settings of chip 10 are in both cases: 00-000-00-000. 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B0W8&layer=L4">report</a></ul>
<!-- Author: Problem DB -->



<!-- Date: Fri Jun 16 19:13:44 2006 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-8748&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-8748  width='300' align='top'></a></td><td><h3>Termination of Store 4772</h3> 
 
<p>The store was terminated via the "The Big Red Button".  As this also latches our BLMs I was curious to see what was recorded.</p> 
 
<p>The store termination was benign for us.</p></td></tr></table>
<!-- Author: Ankush -->


<!-- Date: Fri Jun 16 19:25:27 2006 -->
<table><tr><td><a href=/elog/notebooks/silicon/Fri_Jun_16_2006_192518.ps align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-8750  align='top'></a></td><td>SVXDAQ output of e124 (RA)</td></tr></table>
<!-- Author: Jeannine & Sasha -->

<!-- Date: Fri Jun 16 19:36:46 2006 -->
Entered in Silicon database: <ul>
<li>Ladder: SB1W2L4 
<li>problem n: 1243 
<li>Status: needs_work
<li>Type: Chip_other
<li>Action: Diagnosis_update
<li>entered by: sasha 
<li>description is: This ladder was yellow in SVXMON during past few runs and it had ~100% rate of 'No first chip' errors. ADCMon shows that there is no data from chips 9-13. We tested this ladder in SVXDAQ and confirmed that there is <a href= 'http://www-cdfonline.fnal.gov/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=305&frame=2&anchor=19:25:27'> no data</a> from chips a3-a0 (sometimes a4 as well). We also confirmed that this ladder gives 00_sequence errors (troubled chips are a4-a0). We want to keep this ladder in HWDB for a few runs because it had some miraculous recoveries in the past. If this is not going to happen any time soon, then we want to chop the troubled chips out.  
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B1W2&layer=L4">report</a></ul>
<!-- Author: Problem DB -->



<!-- Date: Fri Jun 16 22:20:57 2006 -->
<h3>CCC and DAQ work</h3> 
 
Today we worked on the CCC-run control interface. Though  
we tested the code in the teststand in the past (see <a href= 
'/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=305&frame=2&anchor=13:07:37'> 
here</a>) we found more problems today when trying the software 
in b0svx02. The problem was that the mvme would not catch the IRQs after the config transition. This was traced to the fact that during the 
config transition something (not clear what) is done to the mvme that screws up the ISR (interrupt routine). This was solved by  
setting the interrupts again after config. The code was tested in all RC states and it worked correctly. We posponed the release of the code till we have time to test it carefully next week. 
<br> 
During the test we tripped some wedges, with was cause while switching clock modes. A config is needed to ensure that the system is fine, though this is upsetting because it beats the idea of the CCC (though problems in any other of the clk signals cause no problems, and we have seen that sometimes switching clk modes will upset the SRC, but not always).<br>
<!-- Author: Mousumi, Bill, Shulamit and Sebastian -->


<!-- Date: Fri Jun 16 22:32:43 2006 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-8751&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-8752  width='300' align='top'></a></td><td><h3>Store 4774</h4> 
 
<p>Inital Lumi: 103.23E30. This is the usual SVTSPYMon.  Looks good.  Silicon included from the <b>start</b> of the store.</p> 
 
<p>Silicon is back in the game :-)</p></td></tr></table>
<!-- Author: Ankush -->


<!-- Date: Fri Jun 16 22:39:29 2006 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-8754&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-8754  width='300' align='top'></a></td><td><h3>Losses at the start of store 4774</h3> 
 
<p>At the start of the store LOSTP started increasing after scraping.  So we held off starting the run.  However it settled around 3kHz and stay=ed there for about 5mins.  At that time I decided to put the silicon in.  Since starting, LOSTP is decreasing. </p> 
 
<p>Unfortunatly we haven't recorded much data for last 30 mins due to L2 and SVT problems.</p></td></tr></table>
<!-- Author: Ankush & Jose -->


<!-- Date: Fri Jun 16 23:41:59 2006 -->
<h3>Silicon back to STANDBY</h3> 
 
<p>We haven't taken data for quite some time.  Also there a chilled water problen at the same time.  So Silicon has gone back to STANDBY.</p>
<!-- Author: Ankush & Jose -->
<!-- Comment: Fri Jun 16 23;50;15 comment by...Ankush -->
<h3>Just realised the ramification of the chilled water problem</h3>

<p>With a chiller having a problem this will eventually affect the detector temperature if we cannot get chilled water.  We have to keep an eye on the detector temperature if the chiller takes some time to repair.</p>


<!-- Comment: Sat Jun 17 09;49;49 comment by...Ulrich -->
<h3>Chilled water: a reminder</h3>
Ankush is right, we had problems with the chilled water last summer when it was hot and dry. This is to remind everybody what the symptoms and possible remedies were:
<ul>
<li>Symptom: SVX chiller cannot hold its set point. <br>
This can be seen from the Alcove temperature in iFix. Normally, the SVX chiller return temperature is between -8°C and -9°C and very stable. The temperature will go up in case of chilled water problems.</li>
<li>Reason: not enough chilled water to SVX chiller.<br>
The chillers use the ECW (electronics cooling water) circuit in their heat exchangers. The efficiency of the heat exchanger depends on the flow and the temperature of the chilled water. According to the chiller technician from RAM, the flow is the bigger issue. With enough flow, the temperature does not matter too much.</li>
<li>Remedy 1: increase chilled water flow to chillers<br>
The chilled water circuit to the chillers does not have a flow meter or a separate pump. However, the flow to the chillers (and to the SUVA) can be increased by closing EV-5 of the ECW circuit. Last summer, it was closed to 30%.
<li>Remedy 2: clean the strainer. <br>
The chilled water goes through a strainer before it arrives at the silicon chillers. Last year, the cryo techs found that this strainer had never been cleaned and was clogged. We do not expect that it is clogged again after just one year.</li>
</ul>
So we (i.e. the Main Pager Carrier and the cooling experts) should have a regular look at the chiller return temperatures in the weeks to come.
<!-- Date: Sat Jun 17 01:40:46 2006 -->
<h3>Lost the Beam!!</h3> 
 
<p>While in the control room watching the SVT boys trying to fix SVT the beam is lost...MCR are working out what happended.</p>
<!-- Author: Ankush -->
<!-- Comment: Sat Jun 17 13;48;15 comment by...Ankush -->
<h4>Helping the SVT Boys</h4>

<p>During the night SVT ran into trouble.  They were losing SNYC on one of their crates due to Bunch Counter mis match. It seem to appear with Silicon.  As the beam had just gone I decided to help these guys out.  So after checking with MCR we were given 1 hour of quiet time. (in the end we had much more).  So we ran the silicon COSMICs tape, with Silicon ON, to feed data from Silicon to SVT. After doing this for about ~30 mins, we realised SVT just needed silicon data....so even noise would be OK. So for safety I put Silicon to STANDBY and ignored all the HV inhibits.  SVT were fed with chip noise.  They were able to get their error with that.</p>

<p>I hung around into the wee hours helping SVT out.  In the end they isolated to a few boards and then their FAKE HITs could generate the error.  At that point (~5:30am) I went home as they no longer needed silicon.  I read in the elog the problem was located to one of their PULSAR boards.  More details in the <a href=
'http://www-cdfonline.fnal.gov/cgi/elog/elog.pl?nb=2006&action=view&page=408&frame=2&anchor=05:59:31.242'>
CDF shift e-log</a>.</p>

<p>In doing this it occured we could try something which could help our SVT brethren and be safe for Silicon. For some SVT tests, they just need FIB headers and c*c*.  So could we not have a run configuration which just reads out the FIB headers without reading out any FIB channels.  (in a similar way we test the GB).  We can help SVT by sending data to them and we do not have to readout our chips...so our ladders stays happy....as long as we have power in the collision hall, thats all that is required.  The detector could even be off......comments anyone ??</p>
<!-- Date: Sat Jun 17 12:38:35 2006 -->
<h3>Chiller Compressor unhappy: SVX and L00 tripped off</h3> 
Here is a list of relevant alarm log file entries: 
<pre> 
6/17/2006  11:30:39.9 [SVXIICON] SVX_CHL_COMP_STATE             CFN               OFF      STATE OF SVX CHILLER COMPRESSOR          
6/17/2006  11:30:41.9 [SVXIICON] SVX_C1306                      CFN              TRIP      PS TRIP/DISABLED SVX-BHW3                
6/17/2006  11:30:41.9 [SVXIICON] SVX_C1305                      CFN              TRIP      PS TRIP/DISABLED SVX-BHW2                
6/17/2006  11:30:41.9 [SVXIICON] SVX_C1304                      CFN              TRIP      PS TRIP/DISABLED SVX-BHW1                
6/17/2006  11:30:41.9 [SVXIICON] SVX_C1303                      CFN              TRIP      PS TRIP/DISABLED SVX-BHE3                
6/17/2006  11:30:41.9 [SVXIICON] SVX_C1302                      CFN              TRIP      PS TRIP/DISABLED SVX-BHE2                
6/17/2006  11:30:41.9 [SVXIICON] SVX_C1301                      CFN              TRIP      PS TRIP/DISABLED SVX-BHE1                
6/17/2006  11:30:43.9 [SVXIICON] SVX_PS_TRIP                    CFN              TRIP      B5W11 layer 0, maybe others              
6/17/2006  11:30:43.9 [SVXIICON] L00_PS_TRIP                    CFN              TRIP      B1W5 layer 3, maybe others               
6/17/2006  11:30:44.9 [SVXIICON] L00_C3302                      CFN              TRIP      PS TRIP/DISABLED L00W                    
6/17/2006  11:30:44.9 [SVXIICON] L00_C3301                      CFN              TRIP      PS TRIP/DISABLED L00E                    
6/17/2006  11:30:45.9 [SVXIICON] SVX_C1801                      CFN               BAD      SVX Chiller Status                       
6/17/2006  11:30:53.0 [CDFS5   ] GEN3_IT_ALM                    COS             ALARM      generator3, current alarm                
6/17/2006  11:30:57.9 [SVXIICON] SVX_CHL_COMP_STATE             OK                 ON      STATE OF SVX CHILLER COMPRESSOR          
6/17/2006  11:30:58.9 [CDF_S1  ] R_SOUND_ALM                    COS       RACKS ALARM      Sound Rack Alarm - CDF3                  
6/17/2006  11:30:59.9 [SVXIICON] SVX_C1306                      OK                 OK      PS TRIP/DISABLED SVX-BHW3                
6/17/2006  11:30:59.9 [SVXIICON] SVX_C1305                      OK                 OK      PS TRIP/DISABLED SVX-BHW2                
6/17/2006  11:30:59.9 [SVXIICON] SVX_C1304                      OK                 OK      PS TRIP/DISABLED SVX-BHW1                
6/17/2006  11:30:59.9 [SVXIICON] SVX_C1303                      OK                 OK      PS TRIP/DISABLED SVX-BHE3                
6/17/2006  11:30:59.9 [SVXIICON] SVX_C1302                      OK                 OK      PS TRIP/DISABLED SVX-BHE2                
6/17/2006  11:30:59.9 [SVXIICON] SVX_C1301                      OK                 OK      PS TRIP/DISABLED SVX-BHE1                
6/17/2006  11:31:02.9 [SVXIICON] L00_C3302                      OK                 OK      PS TRIP/DISABLED L00W                    
6/17/2006  11:31:02.9 [SVXIICON] L00_C3301                      OK                 OK      PS TRIP/DISABLED L00E                    
6/17/2006  11:31:05.9 [SVXIICON] SVX_C1801                      OK                 OK      SVX Chiller Status   
</pre> 
<p> 
We are currently investigating why/how/when our interlocks came back in response to seeing a happy chiller once again.
<!-- Author: Jennifer :-) & Ulrich -->
<!-- Comment: Sat Jun 17 13;30;25 comment by...Jennifer :-) & Ulrich -->
<h3>Summary of investigation</h3>
Here is a summary of the things we checked:
<ul>
<li>The SVX chiller compressor tripped off at 11:30:40. This caused the SVX and L00 power supply enables to trip. </li>
<li>18 seconds later, the compressor switched on again, which enable the power supplies again. The interlock coil C1801 for the SVX chiller status was tripped because X1305 indicated a compressor trip. Note that all chiller status coils do not latch and therefore do not have to be reset by the trip acknowledge buttons. That is the reason why the interlocks were fine again when we arrived.</li>
<li>The question is: why did the compressor trip in the first place. There is no indication that something went wrong with the chiller or the chilled water circuit beforehand. However, there was some problems with the chilled water earlier (see picture below). We will send mail to Andy Hocker and Bill Noe, maybe they remember earlier incidents like this.
</ul>

<!-- Date: Sat Jun 17 12:40:34 2006 -->
<h3>Cooling Trip !!</h3> 
 
<p>SVX + L00 Tripped due to cooling alarm(?)  Investigating now!!</p>
<!-- Author: Ankush, Ulrich & Jennifer :-) -->


<!-- Date: Sat Jun 17 12:44:35 2006 -->
<center><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-8756&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-8756' width='300'></a><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-8755&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-8755' width='300'></a></center>
<!-- Author: Ankush -->
<!-- Comment: Sat Jun 17 12;50;42 comment by...Ankush -->
<h3>Aghhh...Cooling Trip!!</h3>


<p><b>Newbies:</b>This is what a cooling trip looks like!.  Note the lines of "External Trip..External Trip".  Also you can see in IMON that SVX and L00 went red.  Indicating they were all tripped OFF.</p>

<p>When you are main pager carrier and you are paged about a cooling trip, you should ask the ACEs if they see something like this picture.  If you cannot understand them or they cannot describe it to you, use the smiley faces to capture the image.</p>


<!-- Date: Sat Jun 17 12:54:24 2006 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-8757&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-8757  width='300' align='top'></a></td><td><h3>We have to fix this!!!!</h3> 
 
<p>After the cooling trip I brought L00 and SVX back to STANDBY.  I then wanted to take the detector through activate just to exercise it a bit.  But of course I am hit by this DONE TO.  We <b>have</b> to fix this!!!</p></td></tr></table>
<!-- Author: Ankush -->


<!-- Date: Sat Jun 17 13:20:12 2006 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-8758&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-8758  width='300' align='top'></a></td><td>Here is the alcove temperatures and CV-4 and CV-5 from ECW. The compressor tripped off, but nothing indicates a problem shortly before. Certainly, CV-4 was closed around 9:00. Our guess is that the PID loop which steers CV-5, closed it down to 35%. Now this action should give us <em>more</em> flow, not less, so we have even less reason to trip anything. Weird.</td></tr></table>
<!-- Author: Jennifer :-) & Ulrich -->



<!-- Date: Sat Jun 17 13:32:53 2006 -->
Fix  
<a href= 
'http://www-cdfonline.fnal.gov/cgi/elog/elog.pl?nb=2006&action=view&page=409&frame=2&anchor=13:30:44.543'> 
this</a> pinkie, please.
<!-- Author: Jennifer :-) -->
<!-- Comment: Sat Jun 17 18;36;43 comment by...Ulrich -->
<h4>AVDD pinkie in B0L2W1 still there</h4>
The pinkie we saw yesterday is still around. This time, not even an HRR helps to bring it back in line. Apparently, there are chips coming and going. We should use the quiet time to examine the ladder. The pinkie is documented in the 
<a href=
'http://www-cdfonline.fnal.gov/cgi/elog/elog.pl?nb=2006&action=view&page=410&frame=2&anchor=18:17:10.830'>
main e-log</a>.



<!-- Date: Sat Jun 17 18:00:50 2006 -->
<h3>Store 4778: Running with Silicon</h3> 
Store 4778 came in around 17:30 today. The initial luminosity was around 58 e30 cm<sup>-2</sup>s<sup>-1</sup>. All losses were fine, so I decided to include silicon right away.
<!-- Author: Ulrich -->
<!-- Comment: Sat Jun 17 19;05;00 comment by...Ulrich -->
All losses are still very good, and AGIGI2 is stable. So we keep silicon in for the rest of the store. Sasha has the main pager. I have warned him that we are running with silicon, and he should expect pages. The shift crew is instructed to page him in case of questions, problems, etc. I will be available per pager and phone as well.
<!-- Date: Sat Jun 17 18:02:38 2006 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-8760&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-8761  width='300' align='top'></a></td><td>Also SVT is fine for store 4778.</td></tr></table>
<!-- Author: Ulrich -->



<!-- Date: Sat Jun 17 19:02:07 2006 -->
<h3>More on Pinkies</h3> 
I have just posted  
<a href= 
'http://www-cdfonline.fnal.gov/cgi/elog/elog.pl?nb=2006&action=view&page=410&frame=2&anchor=18:57:27.000'> 
instructions into the main e-log</a> to ignore a couple of BIAS line pinkies and the known AVDD pinkie.
<!-- Author: Ulrich -->



<!-- Date: Sat Jun 17 23:42:52 2006 -->
<h4>Trip: I B5 W1 L2 AVDD</h4> 
Got paged for trips in I B5 W1 L2 for the second time tonight. The first time around 9:00, the ace had never recovered a trip before, and I walked her through the procedure. The second time now, the wedge tripped again after being recovered. A second attempt did the trick. 
<p> 
The second time, Sasha on the Main Pager was paged first. The shift crew got impatient already after 5 minutes, so they paged me. 
<!-- Author: Ulrich -->
<!-- Comment: Sat Jun 17 23;47;46 comment by...sasha -->
I got only one page and responded as soon as got to the phone (~1 min). It's strange, Scico told me that they paged me twice, but I got only one page. By some reason I've not been paged for the first trip.  

<!-- Comment: Sat Jun 17 23;51;51 comment by...Ulrich -->
Well, for the first trip, they paged me instead of the Main Pager. Maybe they tried twice now...


<!-- Date: Sun Jun 18 03:03:33 2006 -->
<pre>I was paged because SB1W5L1 tripped and ACE could not recover it. The PS Gui was not responding, so I told ACE to restart it. After PS Gui was up, ACE recovered the trip without problems. After that I was asked by CO about Silimon problems. During my conversation with CO, there was a PS10 problem. I had to explain the ACE (Deepak Kar) how to hockerize the crate. The hockerization was successfull. </pre>
<!-- Author: sasha -->


<!-- Date: Sun Jun 18 08:24:27 2006 -->
<h4>Downtime so far for this store</h4> 
 
<p>I thought I 'd just post this table from the downtime summary.</p> 
 
<P> 
<I>Lost Time is in minutes, Lost Lumi is in nb<SUP>-1</sup>; click on the Down time to go to the approximate Shift eLog time 
<P></i> 
 
 
<TABLE BORDER=2 CELLSPACING=1 CELLPADDING=2> 
 
<TR> 
<TH>Store</th> 
<TH>Category</th> 
<TH>Down</th> 
<TH>DownClink</th> 
<TH>Time</th> 
<TH>Lumi</th> 
<TH>Text</th> 
</tr> 
 
<TR> 
<TD ALIGN=RIGHT><A NAME=ISL_HV><A HREF=/daq/stores/store4778.html>4778</a></td><TD>ISL HV</td><TD><A HREF=/cgi-bin/elog.pl?nb=2006&action=view&page=Sat_Jun_17_2006_Eve&anchor=>2006.06.17 22:20</a></td><TD><A HREF=/java/cdfdb/servlet/DownTimeHistory?DOWNCLINK=1150600800>1150600800</a></td><TD ALIGN=RIGHT>17</td><TD ALIGN=RIGHT>33.5</td><TD><FONT SIZE=-1>Had to reset ISL twice</font></td> 
</tr> 
 
<TR><TD ALIGN=RIGHT><A NAME=ISL_HV><A HREF=/daq/stores/store4778.html>4778</a></td><TD>ISL HV</td><TD><A HREF=/cgi-bin/elog.pl?nb=2006&action=view&page=Sat_Jun_17_2006_Eve&anchor=>2006.06.17 20:05</a></td><TD><A HREF=/java/cdfdb/servlet/DownTimeHistory?DOWNCLINK=1150592700>1150592700</a></td><TD ALIGN=RIGHT>9</td><TD ALIGN=RIGHT>21.8</td><TD><FONT SIZE=-1>Trip in ISL</font></td> 
</tr> 
 
<TR bgcolor=#e0e030><TD ALIGN=RIGHT><A NAME=SVX_HV><A HREF=/daq/stores/store4778.html>4778</a></td><TD>SVX HV</td><TD><A HREF=/cgi-bin/elog.pl?nb=2006&action=view&page=Sun_Jun_18_2006_Owl&anchor=>2006.06.18 00:55</a></td><TD><A HREF=/java/cdfdb/servlet/DownTimeHistory?DOWNCLINK=1150610100>1150610100</a></td><TD ALIGN=RIGHT>57</td><TD ALIGN=RIGHT>91.6</td><TD><FONT SIZE=-1>SVX/ISL power supply trip</font></td> 
</tr> 
 
<TR><TD ALIGN=RIGHT><A NAME=TRIGLVL2><A HREF=/daq/stores/store4778.html>4778</a></td><TD>TRIGLVL2</td><TD><A HREF=/cgi-bin/elog.pl?nb=2006&action=view&page=Sat_Jun_17_2006_Eve&anchor=>2006.06.17 18:28</a></td><TD><A HREF=/java/cdfdb/servlet/DownTimeHistory?DOWNCLINK=1150586880>1150586880</a></td><TD ALIGN=RIGHT>5</td><TD ALIGN=RIGHT>15.4</td><TD><FONT SIZE=-1>SVT issues</font></td> 
</tr> 
 
<TR><TD ALIGN=RIGHT><A NAME=TRIGSVT><A HREF=/daq/stores/store4778.html>4778</a></td><TD>TRIGSVT</td><TD><A HREF=/cgi-bin/elog.pl?nb=2006&action=view&page=Sat_Jun_17_2006_Eve&anchor=>2006.06.17 20:41</a></td><TD><A HREF=/java/cdfdb/servlet/DownTimeHistory?DOWNCLINK=1150594860>1150594860</a></td><TD ALIGN=RIGHT>12</td><TD ALIGN=RIGHT>27.2</td><TD><FONT SIZE=-1>Restart run for SVT experts</font></td> 
 
</tr> 
<TR><TD ALIGN=RIGHT><A NAME=TRIGSVT><A HREF=/daq/stores/store4778.html>4778</a></td><TD>TRIGSVT</td><TD><A HREF=/cgi-bin/elog.pl?nb=2006&action=view&page=Sat_Jun_17_2006_Eve&anchor=>2006.06.17 19:17</a></td><TD><A HREF=/java/cdfdb/servlet/DownTimeHistory?DOWNCLINK=1150589820>1150589820</a></td><TD ALIGN=RIGHT>7</td><TD ALIGN=RIGHT>18.8</td><TD><FONT SIZE=-1>SVT requests shephard b0svt05 and b0svt06</font></td> 
</tr> 
</table> 
 
<p>What can we learn from this.  For the usual PS trips, it has taken the ACES 15-20 mins to recover.  To be honest, that's no so bad for completely new ACEs.  Remember I have insisted the ACEs page silicon first before attempting to recover any silicon probem.  So at least 5 minutes can be attributed to the pager response. Once they get some more experience, I hope this downtime due to PS trips to drop to much smaller value.</p> 
 
<p>...but one entry does stick out.  <b>57 minutes to hockerise a crate!!</b>.  No surprise but this is acssociated to one of our <em>favourite aces</em>. My sympathies to Sasha who to talk him through the whole procedure at 3AM.  An <em>attitude adjustment</em> may be required.</p>  
<!-- Author: Ankush -->
<!-- Comment: Sun Jun 18 14;28;46 comment by...sasha -->
A small correction... Hockerization took a long time, but it wasn't 57 min. There were a few things happening simultaneously. The 57 min of down time which are entered in the logger have to be atributed to a trip recovery for e151, restarting runs (during trip recovery and hockerization, DAQ ACE was starting a new run), and a hockerization. My estimate is that hockerization itself took ~25-30 min---still too long. So, here is how the situation unfolded. I was paged because ACE couldn't recover a trip on e151. PS gui was not responding to his commandes, however it was updating (according to ACE's words). I think this has confused ACE on the first place and made him to page me. So, I asked ACE to restart the GUI and trip was recovered without problems after that. A few minutes later (I was still on a phone talking to CO), PS10 failed, so I was switched back to MON ACE. It appeared that ACE didn't know (he said he wasn't on that lecture) what hockerization is and where to go to do it. So, I had to explain him. ACE failed to hockerize from the first attempt because he couldn't find a power cord (?). He also flipped Off/On 5V enables for SVX---something he shouldn't do at all. After that, I wasn't sure he would be able to do a hockerization, so I asked the second ACE. It turns out the second ACE also didn't know how to do a hockerization, but at least he heard this word. After that, I told MON ACE how to find the instructions for a hockerization on the silicon webpage and he finally was able to do it. I guess my mistake was that I started explaining the ACE about the hockerization instead of pointing to instructions with pictures.     
<!-- Date: Sun Jun 18 12:21:32 2006 -->
<h3>Lots of RXPT errors for b0svx02</h3> 
 
<p>During the current run the shift crew have seen quite a few RXPT errors for b0svx02 followed by a resonnance error. An example can be found <a href= 
'http://www-cdfonline.fnal.gov/cgi/elog/elog.pl?nb=2006&action=view&page=412&frame=2&anchor=11:36:28.265'> 
here</a>.</p> 
 
<p>Our current whipping boy, the CCC, is not to be blamed.  I check the lights on the CCC and I logged into b0svx02 to check it from there.  CCC is still locked to RF and no other errors are present.  So I am now stuck.</p>
<!-- Author: Ankush -->
<!-- Comment: Sun Jun 18 12;23;10 comment by...Ankush -->
<p>forgot to mention there were also L1 DONE Timeouts...this makes it even stranger...</p>


<!-- Date: Sun Jun 18 13:28:18 2006 -->
I have checked the plots from ADCMon for the runstaken so far.  
Most of the ladders are fine giving results comparable to the references before th shutdown. 
<br> 
This is the summary for ladders giving troubles or that are new: 
<li> <b>e084</b> and <b>e404</b> were recovered during the shutdown. They seem to perform well. Perhaps tail from physics is not as high as they should be (pinhole?), but they definetely see physics. Keep them taking data. 
</li> 
 
<li> <b>e0b1</b> and <b>e130</b> were put online during the shutdown. They see signal, but they look as not biased. They are useless for physics in the current situation. Further studies may be needed to recover them.<br> 
<font color=yellow>Need to decide if they are taken out</font> 
</li> 
 
<li> <b>e564</b> did not see physics in run 218620. It sees physics for other runs. However, around 60% of the events have "Unknown channel errors". 
</li> 
 
<li> <b>e012</b> see physics (although not clean behavior from some the chips). It was reported to have unstable AVDD. It seems similar to the state before the shutdown. 
</li> 
 
<li> <b>e244</b> and <b>f002</b> are out of the HWDB after the shutdown. Known. 
</li> 
 
<li> <b>e1a4</b> is bad. It has no data for the runs. <font color=yellow>Need to decide if kept in</font> 
</li> 
 
<li> A couple of ladders with DPS off (known). 
</li>  
<!-- Author: Oscar -->



<!-- Date: Sun Jun 18 22:00:44 2006 -->
<h4>Just added Tuula's Bias Checker web page to main silicon web page</h4> 
 
<p>I have just added a link to Tuula's Bias Checker script to the main silicon web page. You can find the link under <em>Current state of the detector</em>.</p>
<!-- Author: Ankush -->


<!-- Date: Mon Jun 19 01:22:39 2006 -->
<pre>Store 4781 went in with initial lum at ~107. The losses were unstable in the beginning of the store (see plot below), so I asked Steve to call MCR and investigate what was going on. Unfortunately MCR didn't know a reason. I decided to include silicon after losses stabilized and were flat for a few min.</pre>
<!-- Author: sasha -->


<!-- Date: Mon Jun 19 01:23:37 2006 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-8762&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-8762  width='300' align='top'></a></td><td>LOSTP plot from MCR e-log.</td></tr></table>
<!-- Author: sasha -->


<!-- Date: Mon Jun 19 01:31:41 2006 -->
<pre>SPYMon takes forever to make a plot. I gave up after 10 min of waiting. So, no SVT plot for this store...at least for now.</pre>
<!-- Author: sasha -->


<!-- Date: Mon Jun 19 01:34:29 2006 -->
<pre>While in the control room, I gave a brief training session for MON ACE on how to recover trips and hockerize PS.</pre>
<!-- Author: sasha -->


<!-- Date: Mon Jun 19 06:54:18 2006 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-8763&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-8764  width='300' align='top'></a></td><td><h4>SVTSPYMon plot for store 4781</h4> 
 
<p>The usual 3 SVT holes.  Looks like SVT + Silicon are still working.</p></td></tr></table>
<!-- Author: Ankush -->


<!-- Date: Mon Jun 19 06:55:59 2006 -->
I was paged because of freequent resonance problems (<a href= 
'http://www-cdfonline.fnal.gov/cgi/elog/elog.pl?nb=2006&action=view&page=414&frame=2&anchor=06:05:32.390'> 
example from e-log</a>). They were happening every 5 min and ACE got worried something bad may happen, so he halted the run and paged me. I asked him to check lights on CCC---they were OK. The resonances mostly came from the same ladders, they started happening after a prescale change. I didn't know how else to help ACE except asking him to restart the run and see what happens.   
<!-- Author: sasha -->
<!-- Comment: Mon Jun 19 07;03;19 comment by...Ankush -->
<p>This also occured yesterday.  It starts with a series of L1 DONE TIMEOUTs and then we end up with a resonnance. We simply do <b>not</b> get L1 DONE TIMEOUT. Something is not right here.</p>  

<!-- Comment: Mon Jun 19 07;52;44 comment by...Ulrich -->
I saw the problem while reading the elogs from home. I have logged into b0svx02 and checked the CCC via the CCCCC. It was locked to RF and did not show any errors.




<!-- Date: Mon Jun 19 10:57:02 2006 -->
<h3>Week summary</h3> 
 
<p> 
<h4>Monday</h4> 
<lu><li>waiting for the 36x36 store...</li></lu> 
 
<h4>Tuesday</h4> 
<lu><li>Store 4759 with lumi ~30. Problems with AGIGI2 calibration and LOSTP in TEVMON (got fixed later during the day).</li></lu> 
<lu><li>SVX and L00 tripped on overpressure in the supply line (silicon was off).</li></lu> 
<lu><li>Resin ecxange.</li></lu> 
<lu><li>CCC work in preparation for running.</li></lu> 
<lu><li>Store aborted manually on purpose---it was clean for us.</li></lu> 
<lu><li>Store 4760 with lumi ~20. Beam was re-scraped and lumi jumped to ~50.Silicon was not included in the beginning.</li></lu> 
 
<h4>Wednesday</h4> 
<lu><li>Silicon was included at the end of store. TevAbort a few minutes later after silicon was included--- didn't hit us.</li></lu> 
<lu><li>IMon is slow. It generates lots of java processes each consuming ~2% of memory. </li></lu> 
<lu><li>Work on ISL test stand at FCC---still can't power the ladder.</li></lu> 
<lu><li>TevQuench during acceleration--- no hit for us.</li></lu> 
 
<h4>Thurtsday</h4> 
 
<lu><li>CCC commissioned.</li></lu> 
<lu><li>Store 4772 is in with Lumi ~68. Silicon was included after ~1h. </li></lu> 
<lu><li>L2A without L1A SRC error</li></lu> 
 
<h4>Friday</h4> 
 
<lu><li>Quiet time sturdies.</li></lu> 
<lu><li> Store 4774 is in with Inital Lumi: 103.23E30. Silicon was included after a few min when losses stabilized.</li></lu> 
<lu><li>Chilled water problem.</li></lu> 
 
<h4>Saturday</h4> 
 
<lu><li>Store 4774 was lost.</li></lu> 
<lu><li>Cooling trip on SVX and L00.</li></lu> 
<lu><li>DONE TO problem when do COLDSTART.</li></lu> 
<lu><li>Store 4778 is in with initial lumi ~58.</li></lu> 
<lu><li>IB5W1L2 AVDD trip.</li></lu> 
<lu><li>SB1W5L1 tripped. PS10 was hockerized.</li></lu> 
 
<h4>Sunday</h4> 
 
<lu><li>Lots of RXPT errors for b0svx02.</li></lu> 
<lu><li>Store 4781 went in with initial lum at ~107. Silicon was included after a few min.</li></lu> 
<lu><li>freequent resonance problems preceeded by L1 DONE TIMEOUT.</li></lu> 
 
 
</p>
<!-- Author: sasha -->