<!-- Title: 10:23:49  Mon Mar  6 2006 -->
<!-- Crewchief: everyone -->
<!-- Op1: &nbsp; -->
<!-- Op2: &nbsp; -->
<!-- Op3: &nbsp; -->
<!-- Op4: &nbsp; -->
<!-- Op5: &nbsp; -->
<!-- Op6: &nbsp; -->
<!-- Notes: -->
Second week of shutdown - the games continue!


<!-- Date: Mon Mar 6 10:34:21 2006 -->
<h3>DB Work on Wed Mar 8th</h3> 
 
<p>This Wednesday (March 8th), there will be DB work all morning.  So no access for traceSilicon, and other HWDB related matter.</p>
<!-- Author: Ankush -->
<!-- Comment: Mon Mar  6 19;19;35 comment by...Ankush -->
<p>Just read my mail.  The work has been extended to at least 3pm.  So I guess it will be all day.</p>
<!-- Date: Mon Mar 6 10:35:12 2006 -->
<h3>Surveyors this afternoon</h3> 
 
<p>The Surveyors will be measuring the detector this afternoon from 15:50.</p>
<!-- Author: Ankush -->


<!-- Date: Mon Mar 6 10:50:35 2006 -->
<pre>Caen 5V enabled. </pre>
<!-- Author: Jose & Ankush -->
<!-- Comment: Mon Mar  6 12;31;04 comment by...Ankush & Jose -->
<pre>...and Jose and I will be working on the detector today.  

Ulrich: watch out for false pages.</pre>


<!-- Comment: Mon Mar  6 18;16;30 comment by...Ankush & Jose -->
<pre>work for the day finished.  CAEN 5V enables are OFF
All alarms are now real.</pre>
<!-- Date: Mon Mar 6 13:56:17 2006 -->
<h3>LB0W3 may NOT be turned on</h3> 
In order to make a new set of L00 adapter cables, we had to steal the sense adapter off of a working wedge.  We chose to take the adapter from LB0W3 (SW Top Bot, crate 4).  Until we return the wedge, <b>LB0W3 may not be powered!</b><br>
<!-- Author: Jen & Ankush -->
<!-- Comment: Mon Mar  6 14;35;56 comment by...Marcel -->
just in case of protecting against freak incidents, why not pulling the 5V enable of this wedge ?


<!-- Comment: Mon Mar  6 18;21;24 comment by...Ankush -->
<pre>good idea !!...O Joy, another excuse to visit our lovely collision hall :-)
</pre>

<!-- Comment: Wed Mar  8 11;28;24 comment by...Ankush -->
<p>The 5V enable was pulled out this morning.  So remember to put it back in when we get return the adapter.</p>
<!-- Date: Mon Mar 6 18:24:39 2006 -->
Entered in Silicon database: <ul>
<li>Ladder: SB0W0L2 
<li>problem n: 1634 
<li>Status: needs_observation
<li>Type: No_Init
<li>Action: Diagnosis
<li>entered by: amitra 
<li>description is: <p>As part of the Problem DB review I noticed the <em>init readback mask</em> was set even though this ladder initialises fine with no problem in SVXDAQ.  So I've unset the <em>init readback mask</em> for now.  Let's see if runs fine in June</p> 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B0W0&layer=L2">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Mon Mar 6 18:27:57 2006 -->
Entered in Silicon database: <ul>
<li>Ladder: SB0W1L2 
<li>problem n: 1635 
<li>Status: needs_work
<li>Type: Chip_capid
<li>Action: Diagnosis_update
<li>entered by: amitra 
<li>description is: <p>During the Problem DB review this ladder has developed a stuck CAP-ID problem for chip 85.  We should check this ladder later on to see if the problem returns.</p> 
<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: Mon Mar 6 18:34:25 2006 -->
<h3>First step towards the Problem DB review</h3> 
 
<p>As part of my master plan to review all the problem DB entries I have made a start with Jose.  We managed to go through <b>SB0W0 and SB0W1</b>.  We discovered the following: 
 
<ul> 
<li>SB0W0L2 has the <em>init read mask</em> set.  However this ladder initialses fine in SVXDAQ. So I decided to unset this mask.  When we resume data taking we should keep an eye on this ladder.  It does have a history of the <em>init readback</em> coming and going.</li> 
<li>SB0W1L2 has developed a stuck CAP-ID problem for Chip 85.  This ladder should be investigated and it was running fine during recent data taking.</li> 
<li>All other problem DB threads all still correct.</li> 
</ul>   
<!-- Author: Ankush & Jose -->


<!-- Date: Mon Mar 6 18:52:38 2006 -->
<h3>The case of the cut green tube</h3> 
 
<p>Beneath every FIB crate are some water pipes which could be used for water cooling.  However we just use air cooling.  These pipes lead to green piping which eventually descends to a white container which sits in the corner of the collision hall.</p> 
 
<p>It appears the green pipe for the SE FIB rack have been <b>cut</b> and now there is some water leaking from it.  OK, it's a very small amount of water and you <em>really</em> have to shake it to get any out.  BUT...who would dare do such an audacious act?  What should drive one to spur such a cruel action.  These are clearly the actions of a troubled mind.</p> 
 
<p>If you have any information leading to this vicious attack on an innocent green pipe, you can see me and your anonimity will be preserved.  No harm will come to you.  But speak out...otherwise attacks on other green hoses may continue.</p>
<!-- Author: DSI Mitra -->
<!-- Comment: Wed Mar  8 11;27;12 comment by...Ankush -->
<p>The green hosed has been fixed.  So no more drips.  But as to the whereabout of the culprit...that remains a mystery...</p>
<!-- Comment: Thu Mar  9 06;45;52 comment by...SCN -->
It should be said that we <B>do</B> (or at least did) use water cooling in our racks-water flows throught the heat exchangers sandwiched between crates, which in turn cools the air blowing up (down) through our top (bottom) racks-this also explains the locations of the VME crates relative to the CAEN crates, which block the airflow.  Go talk to Pat Lukens about it, he dreamt the whole thing up.  Anyway,   the little green tubes are suppossed to drain the racks via a saftey valve that opens when a drip is detected (suppossedly the supply valves shut at the same time, else you get a small river in the CH).<P>
This historical review of FIB crate cooling brought to you by your friends at MIT...
<!-- Date: Mon Mar 6 18:54:40 2006 -->
<h3>May 10 to May 12:  Silicon Workshop II</h3> 
 
<p>Today the dates for the Silicon workshop at Santa Barbara were fixed.  It will be <b>May 10 to May 12</b>.  The only thing to organise now is the speakers !!!</p>
<!-- Author: Ankush -->



<!-- Date: Mon Mar 6 20:05:34 2006 -->
<h3>No Collision Hall Power Tomorrow (Tuesday) !!!!</h3> 
 
<p>Steve Hahn has just told me the work to the motor generators which provide the 400Hz will <b>ALL BE OFF</b>.  So <b>ALL</b> power to the FIB racks will be <b>OFF</b> from 08:30AM.</p> 
 
<p>The original plan would be to work on one motor generator at a time and they were not going to do it so soon. Aggghhh..grrrrrr</p> 
 
<p>PS: I guess turning off the motor generator will be like hitting the crash button in the control room...O Joy!!</p>
<!-- Author: Ankush -->
<!-- Comment: Tue Mar  7 11;40;51 comment by...Ankush -->
<p>Now I hear the motor generator for the collision hall is still on and they&#39ll work on it tomorrow.  So today we have power.  Tomorrow (??) all FIB racks will be OFF (???)....grrr..</p>

<a href="http://en.wikipedia.org/wiki/Carry_on#Memorable_quotes">
<em>Infamy! Infamy! They've all got it in for me! (Kenneth Williams in Carry On Cleo)</em></a>
<!-- Date: Mon Mar 6 23:59:01 2006 -->
<h3>More news about CAEN Crate 3</h3> 
 
<p>On Friday we heard the CAEN Crate taken to PREP to replace the (two!?!) connectors would not turn on.  THe mystery was solved when it was realised the crates in the collision hall run off 220V but FCC only has 110V mains electricity.  In order to run off 110V some jumpers are set. (That's the big sticker on the front!!).  When this was realised the crate could be turned on and everything looked rosey :-). Hank will then put it through its paces on Tuesday and hopefully we shall have the crate back soon.  Keep your fingers crossed.</p>
<!-- Author: Ankush -->



<!-- Date: Tue Mar 7 12:03:50 2006 -->
<br>  
<b>Testing the CCC wuth the new firmware </b> <br> 
We downloaded the new firmware version, which switches modes (unlock/lock) slower, from Bill to the CCC (CCC3 now has this version as a default). 
The SRC still sees glitches when we change mode (lock/unlock to RF) in average once every ~5 switches.<br> 
The trace shows such a glitch in the SRC and the bottom trace (UBX) shows that the glitch also appears in the CCC. 
 
<br> 
<a href='/elog/notebooks/silicon/Tue_Mar__7_2006_115534.ps'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-8443' ></a>
<!-- Author: Sebastian and Shulamit -->
<!-- Comment: Tue Mar  7 15;37;06 comment by...Sebastian -->
In the above trace RP1 was 96 kOhms, now RP1 is 3 kOhms (turned anticlock to reduce), but still the SRC sees a glitch approx once every 5 switches of mode.
<!-- Date: Tue Mar 7 13:47:39 2006 -->
<h4>Alpha-numeric pager getting cleverer</h4> 
Today I upgraded the mechanism to send e-mails to our new alpha-numeric pager. Now the e-mail contains also the list of iFix tags which went into warning/alarm and are not ignored. For now, I have made the current version of <tt>alarms.exe</tt> official, i.e. it will be started automatically if iFix is restarted. Note that the programs to be started during the iFix startup reside in <tt>C:\Startup\</tt>. The program names are <tt>alarms.exe</tt>, 
<tt>PSMon.exe</tt>, and <tt>TempOut.exe</tt>. These have to be actual programs, no shortcuts (symbolic links) allowed. 
<p> 
In the course of this work, I have also performed the regular reboot of SVXIICON.
<!-- Author: Ulrich -->



<!-- Date: Tue Mar 7 17:58:15 2006 -->
<h2>Checkout of CAEN crate 3</h2> 
Crate 3 came back to us this afternoon, so before putting it back downstairs, I tested it out.  I put all the supplies in the crate and tested them with the loadbox one by one.  Unfortunately, the supply for IB0W3 (this is the supply which was in slot 5, and had a gob of solder on one pin, which has been removed) has developed a new problem - Overvoltage trips on VBIAS00.  It tripped Overvoltage even when set to 0 V!  I tried the supply in slots 5 and 3 of crate 3, then also tried it in our teststand crate, and it tripped the same way every time.<br> 
The good news is, crate 3 checks out fine.  I put the supply from slot 3 (IB1W4) into slot 5 to check that slot out thoroughly; from every slot, I can turn the voltages on every channel, see currents from the CAEN display, and read voltages out of the loadbox.  Since the crate checks out, we'll ask Dervin and co to put it back in SW TT tomorrow.<br>
<!-- Author: Jen, Ankush & Marcel -->


<!-- Date: Wed Mar 8 07:26:05 2006 -->
Got an alpha-numeric page at 7:15, saying that SVX and L00 power supplies went into the alarm state. I assume this is related to the motor generator work. If this is so, it should be documented somewhere, and somebody should be reachable in the control room.  Seems that we have to work out a procedure here.
<!-- Author: Ulrich -->


<!-- Date: Wed Mar 8 07:34:53 2006 -->
Since there is nobody in the control room to check what is going on with the iFix alarms, I called the cryo tech (Dean). He has now silenced the iFix alarms and will ask Dervin for the reason.
<!-- Author: Ulrich -->
<!-- Comment: Wed Mar  8 08;25;00 comment by...Ankush -->
<p>Oops...my fault.  I knew about the motor generator work but didn&#39t make the connection that we would get an iFIX alarm until I was driving in...</p>


<!-- Date: Wed Mar 8 08:26:33 2006 -->
<h3>SW Top Top Crate is back in</h3> 
 
<p>CAEN Crate 3 is back in.  However we cannot test it yet as Motor Generator 3 is OFF which provides the 400Hz power to all the FIB racks.  The power is expected to return around 2pm.  Then we have the joy of powering the detector up.</p>
<!-- Author: Ankush -->
<!-- Comment: Wed Mar  8 10;28;26 comment by...Jen & Ankush -->
<h3>Supplies are back in Crate 3</h3>
We just put the 4 working ISL supplies back into Crate 3 and cabled them up.  As Ankush said above, we won't be able to test them until the power is back up.<br>  We also discovered the problem with the power supply for IB0W3... Looks like somehow, at some point, the potentiometer which controls the Bias0 trip limits has been damaged, nearly knocked clean off the board.  Thus it was tripping Overvoltage because there was no trip limit set, or it looked like 0V.  The good news is this is something Hank should be able to fix quickly.  We're taking the supply back over to him now...<br>




<!-- Comment: Wed Mar  8 16;42;53 comment by...Ankush -->
<p>Hank did an express job for us and Jen already picked up the returned supply and has already tested.  The result:  The module is fixed!! The next step is to put the module into the crate and check everything still works.</p>
<!-- Date: Wed Mar 8 14:14:59 2006 -->
<h3>Update of SVXIICON code - Part II</h3>  
After introducing the automated paging last week, here is another update of the SVXIICON code. It is a reorganization of <tt>PSMon.exe</tt>, the program which reads SmartSocket messages by SVXINTER and copies them into the iFix database. The messages contain a small number of global parameters such as the current state of the power supplies, the highest and lowest voltages in the system, trigger inhibits, etc. In addition, there are voltages and currents for every single ladder - a vast number of database tags. The old code would publish the global parameters and the voltages/currents at the same time, but only with every fourth message, i.e. every 28 seconds. In case the silicon is ramping, the update is enforced with every message (i.e. every 7 seconds), in order to have the global HV iFix page updated regularly. <p> The new code re-organizes the parameters into two groups, global and detailed. The global information is published every 7 seconds, and the detailed information is published every 28 seconds. In addition, I cleaned up the code a little bit. The new code is still pending a test when we ramp the silicon from the global HV page. I have made it official (i.e. copied the executable to <tt>C:\Startup\</tt>, renaming the old executable) and it will be started automatically with iFix. <p> Should somebody have a list of shutdown projects: you can now tick off the code update project. Also thanks to Andy Hocker for explaining the hidden secrets of his code to me.
<!-- Author: Ulrich -->


<!-- Date: Wed Mar 8 14:19:37 2006 -->
<h4>Language barriers</h4> 
Thanks to the excellent communication between Ankush, the SPL, and Jennifer :-), the Ace, Mark is now called Un-Mark.  
<!-- Author: Ankush, Un-Mark, Jennifer ;-), Ulrich -->


<!-- Date: Wed Mar 8 16:22:39 2006 -->
<pre>I have disabled the cron scripts running on b0dap72 at the request of Bill Badgett.  They are doing database work and the database requests from the scripts were causing some problems.</pre>
<!-- Author: Mark -->
<!-- Comment: Wed Mar  8 18;08;00 comment by...Mark -->
<pre>Scripts are reenabled.</pre>
<!-- Date: Wed Mar 8 16:45:07 2006 -->
The motor generator work finished this afternoon; we had hoped to turn on some wedges and look at them in svxdaq.  After doing the following: 
<ul> 
<li>Hockerizing all of the PS crates  
<li>Rebooting all of the fib crates  
<li>Rebooting svxinter 
<li>Restarting PSGui and IMon 
</ul> 
We saw the following error in PSGui when we tried to power a wedge:<br> 
<b>ERROR: Power Supply SVX B2 W2 Handshake - No response from the FIB</b><br> 
This corresponded to an error at the fib:<br> 
<b>FISION: S_errno_EINVAL (0x16): VISIONread(): corrupt handle given</b><br> 
After some detective work by Sebastian we decided there is a good chance that this is being caused by the database work that is currently going on, so we decided to wait until that is done before we start powering up any ladders.<br><br> 
Also we were not able to run cratematch.pl because it does not seemed to have survived recent online cluster changes.  If any alumni have any idea what exactly this script does, an explanation would be greatly appreciated.  
<!-- Author: Ankush,Jose,Sebastion,Mark -->
<!-- Comment: Thu Mar  9 06;48;17 comment by...(Having fun reliving my past) -->
Long live the BootLoader!
<!-- Comment: Thu Mar  9 10;23;29 comment by...Jason -->
cratematch.pl checks that the chips to be readout are the same as the ones to be powered

<!-- Date: Wed Mar 8 16:46:35 2006 -->
<h3>5V enables are off</h3>
<!-- Author: Ankush -->


<!-- Date: Wed Mar 8 16:53:23 2006 -->
<h3>Alarms ignored in iFIX</h3> 
 
<p>With the return of crate 3 I could now unignore the PS-ALARM error in iFIX for ISL.  So the only alarm which still being ignored in iFIX is <b>PS-CAEN-OFF</b>.</p> 
  
<!-- Author: Ankush -->



<!-- Date: Wed Mar 8 20:15:11 2006 -->
I turned on the svx 5V enable.
<!-- Author: s -->
<!-- Comment: Wed Mar  8 20;22;53 comment by...shulamit/sebastian -->
<pre>
--== GUI Startup Complete ==--
Wed Mar 08 20:19:21 CST 2006                        Established communication with iFix
Wed Mar 08 20:19:21 CST 2006                        Interlock is enabled
Wed Mar 08 20:19:28 CST 2006                        success: Power Supply SVX B0 W0 to STANDBY
</pre>
after a lot of work we finally fix the problem and now we can turn on ladders once again. Looks like the DB was the cause of the previous failures.

<!-- Comment: Wed Mar  8 20;25;01 comment by...s/sh -->
will turn the enable off.




<!-- Comment: Thu Mar  9 10;40;35 comment by...Marcel -->
Not surprising, since all the crates came up without the bootloader...


 
<!-- Comment: Thu Mar  9 10;47;55 comment by...s -->
"after a lot of work we finally fix.." that was meant as a joke. 
<!-- Date: Thu Mar 9 09:39:36 2006 -->
<table border=0><td><tr><td bgcolor=#e0e030><pre>5 Volts enabled</pre></td></tr></td></table>
<!-- Author: Jeannine, Sasha -->




<!-- Date: Thu Mar 9 12:20:17 2006 -->
Entered in Silicon database: <ul>
<li>Ladder: SB0W2L2 
<li>problem n: 437 
<li>Status: fixed
<li>Type: jumper
<li>Action: Diagnosis_update
<li>entered by: sasha 
<li>description is: As part of a problem data-base (PDB) review we tried to reinclude z-side: no success  
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B0W2&layer=L2">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Thu Mar 9 12:23:37 2006 -->
Entered in Silicon database: <ul>
<li>Ladder: SB0W2L2 
<li>problem n: 1574 
<li>Status: fixed
<li>Type: Chip_bit_error
<li>Action: Diagnosis_update
<li>entered by: sasha 
<li>description is: As a part of PDB review we started this ladder in svxdaq and we still can confirm readout errors c2c2 after first few events in both RA and NN modes. During data taking this ladder was ok.. 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B0W2&layer=L2">report</a></ul>
<!-- Author: Problem DB -->


<!-- Date: Thu Mar 9 12:25:27 2006 -->
Entered in Silicon database: <ul>
<li>Ladder: SB0W2L3 
<li>problem n: 1462 
<li>Status: needs_bore_access
<li>Type: DVDD
<li>Action: Diagnosis_update
<li>entered by: sasha 
<li>description is: as a part of PDB review we tried to bring this ladder back up: no success 
<li>See <a href="http://b0sili01.fnal.gov/cgi-bin/pdb/DBreport.pl?detsys=SVX&wedge=B0W2&layer=L3">report</a></ul>
<!-- Author: Problem DB -->



<!-- Date: Thu Mar 9 12:32:16 2006 -->
<pre>As a part of PDB review we studied all ladders of SB0B2 and found no new problems. 
We tried to reinclude z-side on layer 2 - no success.  
Furthermore we tried to bring ladder 3 up again - no success. 
Finally we made entries in the PDB concerning our studies. </pre>
<!-- Author: Jeannine, Sasha -->


<!-- Date: Thu Mar 9 12:43:17 2006 -->
<table border=0><td><tr><td bgcolor=#e0e030><pre>5 Volts disabled</pre></td></tr></td></table>
<!-- Author: Jeannine, Sasha -->
<!-- Comment: Thu Mar  9 14;05;23 comment by...Jen &Jose -->
<br>5V enables are back on; we're going into the hall to put IB0W3 back into crate 3.  I just silenced the ISL PS-ALARM, so hopefully no alarms will go off when we turn on crate 3.


<!-- Date: Thu Mar 9 14:52:19 2006 -->
<h3>The end of the CAEN Crate 3 case</h3> 
We went down today to put in the fixed supply for IB0W3.  With some awesome lift-pushing help from siliconeer emeritus David Clark, we got the supply back in and the crate back on.  Now we can turn on every channel, and we ran it all through coldstart.  Everything looks good!  So the saga of the bent pin, which has kept us all awake at night these many long months, is finally settled.<br>
<!-- Author: Jen, Jose, Ankush -->
<!-- Comment: Thu Mar  9 19;04;23 comment by...sebastian -->
nice work.
<!-- Date: Thu Mar 9 15:57:53 2006 -->
<table border=0><td><tr><td bgcolor=#e0e030><pre>5V Enables are OFF</pre></td></tr></td></table>
<!-- Author: Ankush -->


<!-- Date: Thu Mar 9 16:13:31 2006 -->
<h3>iFIX alarm review</h3> 
 
<p>The following alarms are still being IGNORED by iFIX. 
<ul> 
<li>SVX, ISL, L00: PS-CAEN-OFF</li> 
</ul> 
 
I have unignored the ISL IA-CONDUCT (Coolant Conductivity) alarm.</p> 
  
<!-- Author: Ankush -->


<!-- Date: Thu Mar 9 17:35:49 2006 -->
<table border=0><td><tr><td bgcolor=#e0e030><pre>5V enables are ON</pre></td></tr></td></table>
<!-- Author: sasha -->


<!-- Date: Thu Mar 9 17:46:25 2006 -->
After checking the power consuption of the CCC, we put the teststand back together. While checking the system we found that custom.svx is now startup.svx. Everything seems to work.
<!-- Author: Shulamit/Sebastian -->


<!-- Date: Thu Mar 9 18:44:28 2006 -->
<pre>During PDB studies of SB0W3 we confirmed, that all entries in PDB make sense and no new problems have occured.</pre>
<!-- Author: Sasha, Jeannine -->


<!-- Date: Thu Mar 9 18:46:01 2006 -->
<table border=0><td><tr><td bgcolor=#e0e030><pre>5V enables are OFF</pre></td></tr></td></table>
<!-- Author: Jeannine, Sasha -->



<!-- Date: Fri Mar 10 08:16:58 2006 -->
<pre>ISL conductivity now residing at it's 3.0uS/cm high warning. I'll look at the history plots and see if it's "on the rise". I called cryo, and they said that they'd look into it. Also, could conductivity be a function of temperature? We are running ISL warmer...</pre>
<!-- Author: Jennifer :-) -->


<!-- Date: Fri Mar 10 08:25:20 2006 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-8444&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-8444  width='300' align='top'></a></td><td>Funky ISL deionizer loop supply valve behavior; looks like the set point for electro-valve EVF1IN was changed yesterday to change the conductivity; mind you that 3.0uS/cm is our high warning. Steve Hahn now knows about this, and will consult with Bill Noe.</td></tr></table>
<!-- Author: Jennifer :-) -->
<!-- Comment: Fri Mar 10 08;45;06 comment by...Jennifer :-) & Ankush -->
<table border=0><td><tr><td bgcolor=#e0e030><pre>I've re-ignored the ISL IA-CONDUCT; we know about the problem, and we're on it!</pre></td></tr></td></table>


<!-- Date: Fri Mar 10 09:35:14 2006 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-8445&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-8445  width='300' align='top'></a></td><td>Steve Hahn talked to Bill Noe; they re-set the set point to 2.0. (One theory is that the valves were checked since they have not been operated in some time). It will take some time for the conductivity to come back down, so I will keep the ISL IA_CONDUCT as ignore=YES. One thing to notice is that with the resetting of the setpoint, the deionizer loop supply valve does not instantaneously switch over as it did previously. </td></tr></table>
<!-- Author: Jennifer :-) -->
<!-- Comment: Fri Mar 10 11;37;14 comment by...Jennifer :-) -->
<b>The Saga Continues...</b>
Bill Noe would prefer *not* to go through and change resin, etc on a Friday afternoon. I don't blame him. So, this will be addressed first thing Monday morning. Until then I will be on shift Friday and Saturday, so I can monitor what's happening with the conductivity level.
<p>
Ankush brings up a good point... <b>Can a conductivity alarm trip the interlocks</b>, and can we lose flow overnight? And if it does, I get paged... come in... can I acknowledge the trip & re-establish flow with the conductivity still in alarm? I personally cannot fix this, a tech is needed to do conductivity and resin work.
</p>
<!-- Comment: Fri Mar 10 16;39;36 comment by...Jennifer :-) -->
<b>Conductivity will not trip the interlocks</b>
<p>
"Awesome".
</p>
<p>
Let's let the techs deal with this tomorrow; I'll be around. The above statement confirmed by both Steve Hahn and Ulrich.
</p>
<!-- Date: Fri Mar 10 09:37:23 2006 -->
<h3>Monitor Upgrades</h3> 
 
<p>The two silicon monitors are being upgraded.  The tech will also clean out the dirt where the computers are sitting.  So I have shutdown b0dasvx01 and b0dasvx02.  b0dasvx03 is now running IMON and the PS-GUI until the monitor upgrade is complete.</p> 
 
<p>For today, please do not use b0dasvx03 .  If you want to check mail, etc in the silicon office use b0sili01 or b0sili02.</p>
<!-- Author: Ankush -->



<!-- Date: Fri Mar 10 13:42:14 2006 -->
<h3>Silicon Status Scripts Moved</h3> 
The silicon status scripts that used to run as cron jobs on b0dap72, are now running on b0gateway.  This change should not affect anything downstream, as all of the output files are still written to the same place.
<!-- Author: Mark -->



<!-- Date: Fri Mar 10 16:54:37 2006 -->
<center><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-8446&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-8446' width='300'></a><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-8447&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-8447' width='300'></a></center>
<!-- Author: Ankush -->
<!-- Comment: Fri Mar 10 16;57;09 comment by...Ankush -->
<h3>New Monitors</h3>

<p>Check out the snapshots above.  The new monitors have a higer resolution (1600x1200) and are larger!!</p>

<p>In addition, we have acquired a new mouse :-)</p>

<!-- Comment: Fri Mar 10 16;58;45 comment by...Marcel -->
yes, and as usual changing the monitors and getting everything back going was completely transparent 


<!-- Date: Sat Mar 11 08:04:53 2006 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-8448&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-8448  width='300' align='top'></a></td><td>Conductivity still has not risen to the Alarm limit, but it's close! When I was downstairs yesterday in the cryo area, Dean told me that there would be a guy out here in the morning; I'll keep an eye out.</td></tr></table>
<!-- Author: Jennifer :-) -->


<!-- Date: Sun Mar 12 13:26:16 2006 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-8449&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-8449  width='300' align='top'></a></td><td>Conductivity Update! Looks like yesterday evening, the conductivity fell a bit to below the alarm limit (looked to be about 3.7 or so around midnight) and is now in the rise again. I'll talk to Bill Noe 1st thing tomorrow morning, and see if we can adjust the resin levels. This isn't a major concern, but it would be nice to have one fewer thing to worry about.</td></tr></table>
<!-- Author: Jennifer :-) -->


<!-- Date: Sun Mar 12 21:39:24 2006 -->
<center><a href='/elog/notebooks/silicon/Sun_Mar_12_2006_213813.ps'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-8451' ></a><a href='/elog/notebooks/silicon/Sun_Mar_12_2006_213830.ps'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-8453' ></a><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-8454&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-8454' width='300'></a></center>
<!-- Author: Sebastian/Shulamit -->
<!-- Comment: Sun Mar 12 21;45;25 comment by...Sebastian & Shulamit -->
<br>Last week we found that the signals to the svx and isl were different than the ones to the teststand. The first plot on the left shows the delay between BZ and BX for svx. The plot in the middle shows the same delay for the teststand. We modified the delays for the teststand BS signals to reproduce what the CCC sees in the real system. <br>
The plot on the right shows that now we also get BX errors in the teststand. See <a href=
'/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=290&frame=2&anchor=19:00:14'>
this entry</a>.


<!-- Date: Mon Mar 13 08:59:27 2006 -->
<h3>Summary of Shutdown Week 2</h3> 
 
<h4>Conclusion of SW-Top-Top CAEN Crate Work</h4> 
<p>This week the fixed CAEN crate came back from FCC 
and was reinstalled in the collision hall.  The power 
supply for IB0W3 had to be returned to FCC after it was 
discovered the Potentiometer controlling the max. voltage 
trip limit had been damaged.  But this was quickly fixed.</p> 
 
<p>The crate and all the supplies have been tested and it looks 
like the crate+modules are fine :-)</p> 
 
<h4>Problem DB</h4> 
<p>Wedges reviewed: SB0W0,SB0W1, SB0B2 <br> 
<br> 
- SB0W0L2 had <em>init readback</em> removed <br> 
- SB0W1L2 has developed a stuck CAP-ID problem <br> 
</p> 
 
<h4>CCC Work</h4> 
<p> 
- New firmware downloaded which switches mode slower.  But SRC still sees  
glithces ~every 5 swtiches <br> 
- The delays on the Clock Fan Out (?) for the test stand was adjusted to match 
that for the SVX & ISL. <br> 
</p> 
 
 
<h4>SVXIICON Update</h4> 
<p> 
- Alphanumeric page now sends the iFIX tag <br> 
- SVXIICON PC has been rebooted <br> 
- PSMon.exe was reorganised: Global information is published every 7 seconds 
while the detailed information is sent every 28 seconds. <br> 
</p> 
 
<h4>Misc</h4> 
<p> 
- Silicon Workshop Dates Fixed: May 10 to May 12 
- DB Work: Coincided with 400Hz work.  So there weas some problem turning  
ladders on.<br> 
- Surveyors came in <br> 
- The <a href= 
'http://www-cdfonline.fnal.gov/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=291&frame=2&anchor=18:52:38'>Green tube was cut !! </a> (and fixed). It  
also prompted a historical tour from Master Nahn. <br> 
- 400 Hz off for 2 days : no power to FIB racks <br> 
- Moved CRON jobs from b0dap72 to b0gateway <br> 
- New monitors & mouse!! <br> 
- ISL Conductivity has started to creep up.  Fortunatly this will not trip the interlocks. <br> 
 
<h4>Silicon Group Homework : <a href="http://www.carryonline.com/"> 
Carry On</a>
<!-- Author: Ankush -->