<!-- Title: 09:02:50  Mon Apr  3 2006 -->
<!-- Crewchief: Ankush -->
<!-- Op1: Sili Crew -->
<!-- Op2: &nbsp; -->
<!-- Op3: &nbsp; -->
<!-- Op4: &nbsp; -->
<!-- Op5: &nbsp; -->
<!-- Op6: &nbsp; -->
<!-- Notes: -->
<pre>Recover from the power outage 
Prepare for the bore openeing</pre>


<!-- Date: Mon Apr 3 09:04:22 2006 -->
<center><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-8523&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-8523' width='300'></a><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-8524&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-8524' width='300'></a></center>
<!-- Author: ISL & SVX temperatures during our mini-power outage. ISL (already at 15C) showed hardly any warm-up at all; SVX (at 0C) rised about 3 degrees overall. Back to plug-pulling operating temperatures. Jennifer :-) & Ulrich -->
<!-- Comment: Mon Apr  3 09;12;53 comment by...Jennifer :-) & Ulrich -->
Also, FYI: the earlier warm-up (around 16:00 yesterday 04/02) was our changing of setpoints. See <a href=
'http://www-cdfonline.fnal.gov/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=294&frame=2&anchor=17:06:26'>
last weeks e-log</a>. Notice that temperatures came up rather quickly; up 5°C in ISL and up 6°C in SVX in just under 2 hours.
<!-- Date: Mon Apr 3 09:11:52 2006 -->
<h3>Cooling during the power outage</h3> 
Yesterday evening, we went through our new  
<a href="http://www-cdf.fnal.gov/~husemann/internal/expert/cooling/power_outage.html"> 
checklist for power outages</a>. So we thought we were prepared. This is what happened then: 
<ul> 
<li>The power went off almost exactly at 7:00. The diesel generator kicked in for a second, but went off right away. So: no iFix controls, no vacuum pumps, no backup pumps, no nothing!</li> 
<li>The power came back around 7:20, with another short glitch 10 minutes later, compatible with the diesel generator switching off again.</li> 
<li>In order to let the ISL chiller compressor kick in, we had to close the manual bypass a little. 
<li>Flows were re-established without major problems. The manual bypass had to be re-opened to get enough flow to the ISL.</li> 
</ul> 
Apart from that, we also had the problem that the RT server on <tt>b0server05</tt> could not be contacted (although Bill Badgett promised the RT server would be up during the power outage). So our temperature and PS monitoring programs on SVXIICON would not run.
<!-- Author: Jennifer :-) & Ulrich -->
<!-- Comment: Mon Apr  3 14;40;09 comment by...Ulrich -->
<br>Here is an explanation by Bill Noe as of why we did not have backup power (taken from the cryo e-log)
<pre>
Last week the diesel generator was "load tested" by an outside contractor and supervised by FESS. They left a switch in the "off" position which operates the transfer switch. This switch is behind a locked panel. It has since been placed in the on position so the transfer switch should function properly for the next power outage.
</pre>
Maybe, these guys need a checklist, just like ours...
<!-- Date: Mon Apr 3 09:15:45 2006 -->
<h3>False SVX integrated dose alarms</h3> 
During and after the power outage, we had two false dose alarms, which we had to silence in the control room. We called up MCR to ask if they had power-cycled anything. They had not but found it likely that someone else did.
<!-- Author: Jennifer ;-) & Ulrich -->



<!-- Date: Mon Apr 3 19:01:19 2006 -->
<h3>Plugs are apparently open</h3> 
Apparently, the work to open both plugs has been concluded today. Not a single line about this can be found in the e-log. I have got this information from Steve Hahn.
<!-- Author: Ulrich -->


<!-- Date: Mon Apr 3 19:35:31 2006 -->
<h3>Post Power Outage DAQ Problems</h3> 
After this morning's power outage we decided to move the fibers going to VRB_61, as well as the VRB, from b0svx08 slot 8 to b0svx06 slot 17.  This is the last step we needed to do as part of the VRB load balancing.  After making the swap, we updated the VRB_61 entry in cardEditor as follows: 
<ul> 
<li>CR_CRATENAME: VRB_ISL_08 -> VRB_ISL_06 
<li>SLOT: 8 -> 17 
<li>MINIBANK: 9 -> 7 
<li>SCPU: B0EVME25 -> B0EVME23 
<li>MONITOR: B0SVX08 -> B0SVX06 
</ul> 
We also updated the isl.links, b0svx06.crate and b0svx08.crate files for svxdaq.  After this we initialized the SRCs and everything seemed fine in svxdaq except that the ISL ghostbuster was not working (eventually this was fixed, at least temporarily).  Next we tried running RunControl and the system went through Config fine, but was giving L1 Done Time Out errors for b0svx06.  This seemed strange because we were able to trigger on the L1D signal with the logic analyzer.  We next tried putting the fibers, boards and database settings back to how they were before the moving VRB_61, but we still saw the same error.  We also tried testing the Trigger Supervisor by swapping TS cables and also running the teststand from RunControl.  Neither of these tests were successful.  We are calling it quits for tonight and will tackle this problem again tomorrow.
<!-- Author: Mark/Ankush/Sebastian -->


<!-- Date: Tue Apr 4 11:11:11 2006 -->
<pre>svxiicon rebooted yesterday.</pre>
<!-- Author: Jennifer :-) -->


<!-- Date: Tue Apr 4 13:12:04 2006 -->
<h3>Work on backup chiller ongoing</h3> 
Another update from the <a href= 
'http://www-cdfonline.fnal.gov/cgi/elog/det-system-elog.pl?nb=cryo-gas&action=view&page=1884&frame=2&anchor=13:00:58'> 
cryo e-log</a>: 
<pre> 
Silicon Spare Chiller Update 
Gary from Ram Mechanical has replaced the leaky condenser on this machine. He is in the process of making the system tight and ready to run. Should be available again before the end of week.  - Bill Noe 
</pre>
<!-- Author: Ulrich -->


<!-- Date: Tue Apr 4 13:35:32 2006 -->
<pre>COT work has begun: decreased COT flows, increase in silicon flow. According the their JHA, see bottom of page 5. Ankush and Ulrich are here.</pre>
<!-- Author: Jennifer :-) -->
<!-- Comment: Tue Apr  4 14;00;49 comment by...Ulrich -->
The flows are changed, and the only change in the dewpoints was the COT East baggie dewpoint, which dropped from -27°C to -28°C. This is correlated with a drop in temperature from
18°C to 17°C.

<!-- Comment: Tue Apr  4 14;09;44 comment by...Ulrich -->
Here is a little ROOT script to calculate the dewpoint as it is done in the PLC:
<pre>
double dp( double* x, double *par )
{
  // empirical constants
  const double c1 = 238.3;
  const double c2 = 17.2694;

  // temperature in celsius
  double te = x[0];

  // relative humidity in % (cut-off at 3%)
  double rh =  TMath::Max( 0.03, x[1] );

  // dewpoint calculation: Magnus formula
  // see e.g. http://en.wikipedia.org/wiki/Dewpoint
  double gamma = c2 * te / ( te + c1 ) + log( rh );
  double dp = c1 * gamma / ( c2 - gamma );

  return dp;
}

void dewpoint()
{
  gStyle->SetPalette( 1 );
  TF2* fdp = new TF2( "fdp", dp, -30, 10, 0, 1, 0 );
  fdp->Draw( "colz" );
  fdp->GetXaxis()->SetTitle( "temperature (^{#circ}C)" );
  fdp->GetYaxis()->SetTitle( "relative humidity" );

}
</pre>

<!-- Comment: Tue Apr 4 21:26:56 2006  comment by...Ankush --> 
<center><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-8526&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-8526' width='300'></a><a href='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-8525&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-8525' width='300'></a></center>





<!-- Comment: Tue Apr  4 21;39;52 comment by...Ankush -->
<p>This formula is used by the ROOT macro and our PLC to calculate the <a href="http://en.wikipedia.org/wiki/Dew_point">dewpoint</a>. The symbols are:</p>

<ul>
<li>T_d : The dew point in centigrade</li>
<li>T : The ambient air temperature</li>
<li>RH : The Relative Humidity which ranges from 0.0 to 1.0</li>
<li>b :237.7 C</li>
<li>a : 17.27 C</li>
</ul>

<p>One should note the Dew Point depends on the log of the humidity...but a Ulrich wisely pointed out, the log changes quite a bit from 0.0 to 1.0 (!).</p>
<!-- Date: Tue Apr 4 15:20:42 2006 -->
<h3>Concerning Yesterday's Problem with the ISL SRC</h3> 
Attempts to debug the problems encountered <a href= 
'http://www-cdfonline.fnal.gov/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=295&frame=2&anchor=19:35:31'> 
yesterday</a> while running the ISL in Coldstart configuration came to a halt this morning when a number of runcontrol crates (including the trigger supervisor crates) became unresponsive.  It turns out that this was due to a <a href= 
'http://www-cdfonline.fnal.gov/cgi/elog/elog.pl?nb=2006&action=view&page=245&frame=2&anchor=12:06:29.950'> 
problem</a> with b0vxboot02, and in the processes of fixing this, the trigger supervisor crates were rebooted.  Apparently this solved our problem, and we are now able to run Coldstart through 5000 events without errors.
<!-- Author: Mark&Ankush -->
<!-- Comment: Tue Apr  4 15;21;32 comment by...Mark -->
BTW, the important lesson that we learned is to always blame other people first.

<!-- Comment: Tue Apr  4 15;46;43 comment by...sebastian -->
yes, at least do not blame the SRC


<!-- Date: Tue Apr 4 16:03:19 2006 -->
<table border=0><td><tr><td bgcolor=#e0e030><h3>Phone Numbers in the Bore</h3> 
Both ends of the bore will have phones for the duration of the bore access.  The numbers are: 
<ul> 
<li> East Side - 6788 
<li> West Side - 6785 
</ul></td></tr></td></table>
<!-- Author: Mark -->


<!-- Date: Tue Apr 4 16:48:38 2006 -->
The COT people (Bob and Morris) started their bore work. They slit the COT East baggie at around 9:00 (i.e. at 180°) and resealed it with some tape. During this time, we monitored the dewpoints and performed a short visual inspection. The silicon baggie dewpoints were perfectly stable. As expected, the COT dewpoints (East and also West to a lesser degree) went up from -27°C to around -14°C (East) and -21°C (West), mainly due to the increased humidity of around 5-7%.  
<!-- Author: Ankush, Mark, Ulrich -->


<!-- Date: Tue Apr 4 16:55:34 2006 -->
<h3>More on VRB Load Balancing</h3> 
Yesterday we made the final change for the VRB load balancing.  We moved VRB_61 and its fibers from b0svx08, slot 8 to b0svx06, slot 17.  Now that our trigger supervisor problems are fixed, it appears that the DAQ system is functioning properly with all of the changes for the load balancing.  It still remains to be seen how EVB and L3 will handle the changes.  As a final checkout I reran the FIB2VRB test on all of the FIBs/VRBs that we touched for the load balancing, which are in the table below.  All of these ran error free. 
<br> 
<br> 
<table border="1"> 
<tr> 
<td><b>FIB</b></td><td><b>Crate</b></td><td><b>Slot</b></td> 
<td><b>VRB</b></td><td><b>Crate</b></td><td><b>Slot</b></td> 
</tr> 
<tr> 
<td>FIB_39</td><td>b0fib01</td><td>12</td> 
<td>VRB_51</td><td>b0svx06</td><td>18</td> 
</tr> 
<tr> 
<td>FIB_40</td><td>b0fib01</td><td>16</td> 
<td>VRB_67</td><td>b0svx08</td><td>18</td> 
</tr> 
<tr> 
<td>FIB_43</td><td>b0fib03</td><td>11</td> 
<td>VRB_52</td><td>b0svx06</td><td>20</td> 
</tr> 
<tr> 
<td>FIB_46</td><td>b0fib03</td><td>17</td> 
<td>VRB_66</td><td>b0svx08</td><td>16</td> 
</tr> 
<tr> 
<td>FIB_41</td><td>b0fib03</td><td>9</td> 
<td>VRB_61</td><td>b0svx06</td><td>17</td> 
</tr> 
<tr> 
<td>FIB_49</td><td>b0fib05</td><td>11</td> 
<td>VRB_48</td><td>b0svx06</td><td>10</td> 
</tr> 
<tr> 
<td>FIB_51</td><td>b0fib05</td><td>16</td> 
<td>VRB_56</td><td>b0svx07</td><td>13</td> 
</tr> 
<tr> 
<td>FIB_54</td><td>b0fib07</td><td>11</td> 
<td>VRB_47</td><td>b0svx06</td><td>9</td> 
</tr> 
<tr> 
<td>FIB_56</td><td>b0fib07</td><td>16</td> 
<td>VRB_58</td><td>b0svx07</td><td>16</td> 
</tr> 
</table>  
<!-- Author: Mark -->


<!-- Date: Tue Apr 4 19:05:20 2006 -->
<h3>Plans for the webserver move.</h3> 
 
<p>During Monday's SiOps meeting, I was asked if there was a timeline for the webserver move.  After browsing through my email I found the email.  In short, the elogs will be moved this week.  Next week the web pages will be moved. Below is the email I received from Willis:</p> 
 
<pre> 
Dear SPLs: 
       The decision has been made to proceed with the proposed web server move based on the file mapping sent out this week. This is to inform you of the plan for the next two weeks. 
 
1) 03-07 Apr 2006 
   - Move the elogs over to the new server. Most of the week will be 
     for test/checkout of the elog system in the new server. During 
     this period, the elogs in the old server will be active and be 
     the primary elog. 
   - When the elog system on the new server is validated, the 2006 
     elog on the old server will be frozen and copied to the new one. 
     This elog on the new server will then be activated, and it 
     will become the primary elog. This is expected to happen in the 
     latter half of the week, or early on in the next week. 
2) 10-14 Apr 2006 
   - The web area from the old server will be copied over to the 
     new web server. The copying will take a few hours. 
   - The web areas will be "frozen" (ie no changes allowed) for some 
     time during the week.  
   - The shift crews will be given the task of going through all the 
     web pages to find broken or problem links. To assist the shift 
     crew in this checkout, it will be useful if Detector groups have 
     a list of web pages/items to be checked out -- this information 
     should be sent to CDF Ops. 
   - We will be setting up a web page to report problems and to email 
     the problem to CDF Ops, the CD System Admins, etc. The idea is to 
     use this to track the problem frequency for the upcoming decision 
     on the tenability of the new web file structure, and to get any 
     all reported problems fixed promptly. 
     > Smaller and easier problems can be fixed by the shift crew and/or 
       CDF Ops. We still need to work out the details on this. 
     > If the problem is system related or if a big chain of links have 
       problems -- this is for Stephan Lammel and Jason Heddon. They 
       will also be available to help out on other things as well.  
 
There are issues and items on the to-do list. These are 
 a) Merge the "ops" and "det" top level directories into one: "ops" 
 b) Prior to the week of 10 Apr 2006, the week the shift crew will be 
    testing/checking the new web server, Stephan Lammel will provide 
    a new web page where one can enter a description of the problem. 
    This will then be emailed to an appropriate email list. Aside from 
    the SysAdmins, we have not yet settled to whom email will be sent. 
 c) Feasibility of modifiying web content from someplace other than 
    the new web server machine. 
 d) Disaster recovery plan for the new web server machine. 
 e) Appoint a "neutral" observer to review and make suggestions on our web  
    server move. The review will be going on in parallel. 
 
                                               -- Pat, Peter, and Willis 
 
                                                  CDF Operations 
</pre>  
 
  
<!-- Author: Ankush -->


<!-- Date: Tue Apr 4 19:47:18 2006 -->
<font color="red"><h3>DO NOT USE ANY SILICON UNTIL FURTHER NOTICE</font></h3></font> 
 
<p>Today in the control, the CDF DAQ (not Silicon) had a lot of trouble concerned with b0vxboot02.  This <em>boot node</em> made the rest of the CDF crates (including the TSI) acting funny.  Although it took them longer before they started hitting problems.  So Bill has been trying to fix it for CDF.</p>  
 
<p>but....</p> 
 
<p>in the process of trying to fix things Bill accidently flashed the wrong kernel version to fib00 to fib04.  Now none of these fibs will boot.  The only fix is to go to the collision hall and pull out the MVME CPU and do some jumper moving.  Fortunatly we are in shutdown and the detector is off.  But this is still a hassle as the walls and arches are out so access is a little less than favourable.</p> 
 
<p>I will be dragging Bill with me into the collision to undo his handy work.</p> 
 
<p>I should add Bill is quaking in his boots and looks quite scared.  Clearly the inherited fear of past SPLs is being refleced off me.</p> 
 
 
  
<!-- Author: Ankush -->




<!-- Date: Wed Apr 5 09:11:04 2006 -->
<h3>Plan for SVXIICON iFix upgrade</h3> 
We have a plan for the upcoming iFix upgrade. We want to have our dewpoint monitoring up and running during the COT bore work. These values are obtained from the iFix database of SVXIICON. So Mark Knapp agreed to start his work tomorrow morning at 6:30, and Bob Wagner agreed to wait with the COT work until Mark is done. 
<p> 
Mark started his work today by copying over the database, which should not interfere with anything. In fact, the high load on the database caused a transient iFix alarm in the control room.
<!-- Author: Ulrich -->


<!-- Date: Wed Apr 5 11:28:46 2006 -->
<h3>FIB Crates are back :-) !!!</h3> 
 
<p>Today Bill and I had a merry little trip to the collision hall to undo his handiwork.  We went to fib00 to fib04 and pulled out each CPU to move a jumper to boot the default kernel. Bill then flashed the current kernel to the CPU and and then another a jumper move. All this involved a couple of power cycles of the fib crates.</p>  
 
<p>When I headed back to the Control Room, I checked all the FIBs could be rebooted..which they did fine.  I then tried to open SVXDAQ to resync all the GLINKS. However SVXDAQ would stall on "open connection".  I then went to Run Control to do a COLDSTART and svx01 would not pass partition.  I then tried PINGing and vxcom but both failed.  So I rebooted the CPU.  Then svx01 passed  partition.  I took the system to ACTIVATE and let it run for 5,000 events. It ran fine with no errors.  I then went to SVXDAQ and it opened with no problems this time.  The SRC, FIB, FFO, and VRBs are looked fine.</p> 
 
<p>So it looks like everything went back to normal..<em>I hope</em>.</p>
<!-- Author: Ankush -->


<!-- Date: Wed Apr 5 14:27:15 2006 -->
<h3>Online Web Server Move Update</h3> 
 
<p>Yesterday I sent Stephan an email with some questions about the online webserver move.</p> 
 
<p><em>- Will the new online webserver preserve the same "name" ?  ie:- the new webserver will still be "http://www-cdfonline.fnal.gov/"<br>  
    - in addition the svxii web pages will still reached at http://www-cdfonline.fnal.gov/~svxii ?<br></em></p> 
 
<p>Stephan said the new online websever will still have the same name (http://www-cdfonline.fnal.gov) but the svxii web page will not be reached at http://www-cdfonline.fnal.gov/~svxii but it will be http://www-cdfonline.fnal.gov/~ops/svxii (or something similar to that).  So our online web address will change.  This will affect the bitreporter perl script, other scripts and certainly one CRON job.  I asked Stefan whether the exclusion of the APACHE module to preserve the svxii online web address was due to security.  It didn&#39t appear to be so.  He will monitor how often www-cdfonline.fnal.gov/~svxii is called for. He will put in place a link to forward www-cdfonline.fnal.gov/~svxii to the new address.  This may get reviewed depending on what happens.</p> 
 
<p>I emphasised this was not desirable for us as we would have to edit our scripts and links to the svxii online page from external sites would not be aware of this change.  I also mentioned links from our pages would need to be edited.  But the script which copies the web pages will resolve the links for us.</p> 
 
<p><em>We have a CRON job which copies a file from the online machine via wget.  Will this still be possible with the new web server ?<br> 
The command that's in our list of CRON jobs is:  
                /usr/bin/wget -q -N -O /usr/local/apache2/cgi-bin/ladsin/ladsin.txt http://www-cdfonline.fnal.gov/~svxii/ladsin.txt ?</em></p> 
 
<p>The answer is that wget will not get affected by the webserver move.  But as the example above shows, this CRON job would fail as the web address for svxii will be different.</p> 
 
<p><em>We have some files which are soft linked from the public_html to directories out of this. Can these files be seen with the new webserver ? 
eg:- we have the file ~svxii/public_html/errsum.txt which is actually a soft link to ../lester_tools/errparse/errsum.txt.<br> 
(We use this file to check the bit errors coming out of the silicon detector...so it's rather important.)</em></p> 
 
<p>Anything outside of public_hmtl will not be accessable to the webserver, only /data and one other will be accessable to the web server. So the soft link above will not work.  Stephan will look into this and see if there can be workaround.  Otherwise we will need to edit our soft links and other move them inside public_html or we will need to edit the scripts which call upon them.</p> 
 
<p><em>- What will happen to the old server once all the files have been copied ?</em></p> 
 
<p>The old webserver will be availabe for some time to help resolve broken pages and links.</p> 
 
<p><em>After all the webserver moves have been completed, could you send out a list of the how to map from the old directory to the directories on the new web server.</em></p> 
 
<p>Such a page will exist on the new webserver.</p> 
 
 
<p>From our side the most serious are the change of the web address of the web page for the svxii account and the inability to resolve soft links to targets outside of public_html.  Both of this will generate work as we would need to edit scripts and check they still work.  Also external links to the online silicon page will be broken and it is hard to advertise the change as we wont know who they are a priori.</p> 
 
<p>as the bit reporter seems to be most affect by this, we may want to move it to b0sili01 as this will give us greater control over it.  Any comments from anyone else ?</p> 
 
 
 
 
   
<!-- Author: Ankush -->
<!-- Comment: Wed Apr  5 15;33;45 comment by...Mark -->
The bitreporter is already on b0sili01.  The reason it is affected by the move is that it accesses files on the online machines using http:

<pre>
$svxErrors="http://www-cdfonline.fnal.gov/~svxii/errsum.txt";
$tempfile="/tmp/errsum_$ENV{USER}.dat";
$html = $ua->request( GET($svxErrors), $tempfile );

This file comes from one of the cron jobs and is at:

[b0gateway.fnal.gov] pwd
/cdf/onln/home/svxii/public_html
[b0gateway.fnal.gov] ls -l errsum.txt
lrwxrwxrwx    1 svxii    cdf            35 Oct 12 09:57 errsum.txt -> ../lester_tools/errparse/errsum.txt
</pre>

So if we modify the cron job to write to the new web area, and change the web address the bitreporter looks at we should be fine.

<!-- Comment: Wed Apr  5 16;14;31 comment by...Marcel -->
well, it is not that easy, because you have to modify all the jobs, that write files on lester_tools and are then http'd to b0sili01. The reason for having a load of things on b0sili01 was to be more independent of online computing troubles. 
One could consider now to become completely selfsufficient, by copying/transfering the files after they are generated to b0sili01 and have always a copy ready, soeven if the whole online cluster collapses, you still have ProblemDB, Bitreporter, etc.
another thing that will break for sure is the Powersupply converter. That would also require some fixing. In my mind, all of these things are not major, but we'll spend another good chunk of time, till everything is debugged and every little broken link has been found. And keeping <pre>www-cdfonline.fnal.gov/~svxii </pre> does not cost you anything. Most of the things are actually not because of security issues, but because Stephan wants to reorganize things in a way, he thinks is convenient (for him ). Has it already been made clear where all the cron jobs are going to run that copy stuff from to the web areas ?.
Without having write access and/or softlinks, that will require some duct tape solutions which would be exactly diametral to the proposed ease of use. <br>
e.g Cron job generates files, copy files to data area, copy it from  there to public_html area, does not sound very robust to me.




<!-- Comment: Wed Apr  5 17;20;55 comment by...Mark -->
I realize that there are additional jobs other than <b>dailyupdate</b> (which creates errsum.txt) that will need to be modified.  I was just using that as an example.  I think we are all in agreement about what will break.  So the question that we need to ask is: do we take this opportunity to modify the scripts to write outputs to b0sili01?  Since we are forced to modify both the cron scripts and the bitreporter scripts even if we continue to use the online webserver to transfer the files, I think we should just go ahead and start storing the files on b0sili01.  Another advantage to doing that is that we can implement the changes without having to wait for the online web server changes.


<!-- Date: Thu Apr 6 06:37:07 2006 -->
<h3>iFix Upgrade</h3> 
Mark Knapp has started to upgrade iFix on SVXIICON from iFix 3.0 to iFix 4.0.
<!-- Author: Ulrich -->
<!-- Comment: Thu Apr  6 07;55;03 comment by...Ulrich -->
Mark is done with the upgrade. He did not encounter any problems other than the fact that our software key had the wrong license. He exchanged the key with the key of a test PC. The stand-alone executables compiled with iFix 3.0 ran fine with iFix 4.0. Just to be sure, I have recompiled them (no problems found). What remains to be done after the COT work is finished: run the newly compiled stand-alone programs, check if alarm logging to a file is enabled.


<!-- Comment: Thu Apr  6 18;46;56 comment by...Ulrich -->
Finished the last test with the new iFix version. The newly compiled stand-alone programs run fine, and the alarm logging is back (it&#039;s called "Alarm History" in the SCU). Tomorrow morning, Mark Knapp will install the correct hardware key for the PC, either before the COT work starts (around 7:30) or during the Secretary-of-Energy break. 
<!-- Comment: Fri Apr  7 07;10;14 comment by...Ulrich -->
Mark has exchanged the hardware key this morning. This concludes the iFix upgrade on SVXIICON. The next thing planned for the machine is a fresh harddisk image (Mark has to open the PC and plug in the second drive for that) but only after checking the upgraded iFix is stable over a couple of weeks.
<!-- Date: Thu Apr 6 07:56:10 2006 -->
The COT people have started their work for today. Until the morning shift crew arrives, I will watch out for temperatures and dewpoints.
<!-- Author: Ulrich -->


<!-- Date: Thu Apr 6 08:02:39 2006 -->
<h3>Update on Spare Chiller Status</h3> 
Bill Noe posted an update in yesterday&#039;s 
<a href= 
'http://www-cdfonline.fnal.gov/cgi/elog/det-system-elog.pl?nb=cryo-gas&action=view&page=1885&frame=2&anchor=10:42:29'> 
cryo e-log</a>. The bottom line is: no spare chiller until next Monday. 
<pre> 
Silicone Spare Chiller Update 
Gary (from RAM) tells me there is one more leak to fix on the spare chiller. It is on a small ball valve in the refrigerant circuit. Gary has to get the valve and can't replace it until Monday. So the chiller remains out of service until early next week. The condenser has been changed and it tested fine.  - Bill Noe 
-- Wed Apr 5 13:59:43 comment by...Bill Noe --   
Update on the Update 
So Gary got the valve changed this afternoon. He has leak checked it six ways to Sunday and can't find a leak. He has it pressurized and will pull a vacuum on it on Monday and will charge it at that time. 
</pre> 
 
  
<!-- Author: Ulrich -->


<!-- Date: Thu Apr 6 18:28:42 2006 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-8528&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-8528  width='300' align='top'></a></td><td>What we get with the new firmware we got from Bill today. The delay register shows 0 but the trace is not consistent with what we got <a href= 
'/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=292&frame=2&anchor=20:08:27'> 
before</a>. 
 </td></tr></table>
<!-- Author: Sebastian and Shulamit -->
<!-- Comment: Thu Apr  6 18;30;04 comment by...Sebastian/Shulamit -->
<pre>RC gives SRC/TS errors which are consistent with the wrong clock signals because of the wrong delay.</pre>




<!-- Date: Fri Apr 7 07:44:27 2006 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-8529&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-8529  width='300' align='top'></a></td><td>Dew points over the first three days of the bore access.</td></tr></table>
<!-- Author: Ulrich -->


<!-- Date: Fri Apr 7 10:24:22 2006 -->
<h3>Updated svxdaq Configuration Files</h3> 
The svxdaq configuration files have been updated with the latest hardware database settings.  If you run into any problems, let me (Mark) know.
<!-- Author: Marcel/Mark -->


<!-- Date: Fri Apr 7 15:56:42 2006 -->
<h3>Access to Update GLink Fiber Labels</h3> 
Tuula and I made an access this afternoon to fix all of the labels for the glink fibers that were moved for the VRB load balancing.  After adding the new labels (which involved unplugging some of the fibers and moving them around to clean things up), I took the system through a Config and ran the FIB2VRB tests for all of the fiber we touched.  Everything looks good.
<!-- Author: Mark&Tuula -->


<!-- Date: Fri Apr 7 16:06:44 2006 -->
<font color="red"><h3>Return your Keys</h3></font> 
 
 
<p>This is your 1 hour countdown: Please return your keys and badges to the control room !!!</p> 
  
<!-- Author: Ankush -->


<!-- Date: Mon Apr 10 10:32:05 2006 -->
<br> 
<b>Weekly Summary </b> 
<li> <b>Monday </b> - Power outage,  Ulrich was here to take care of the cooling, there were two integrated false dose alarms. In addition there were DAQ problems due to a problem with b0vxboot02. Problem was fixed when the TS was rebooted. 
<li> <b>Wednesday </b> - Started backing up the database for SVXIICON iFix upgrade. 
Ankush and Bill brought back the FIB crates.  
<li> <b>Thursday </b> - iFix upgrade started. 
<li> <b>Friday </b> - svxdaq configuration files have been updated with the latest hardware database settings . 
Tuula and Mark went on access to fix all of the labels for the glink fibers.
<!-- Author: Shulamit -->