<!-- Title: 08:22:07  Sun Feb 25 2001 -->
<!-- Crewchief: Matt Herndon -->
<!-- Op1: Steve Nahn -->
<!-- Op2: Jean Slaughter -->
<!-- Op3: David Stuart -->
<!-- Op4: Tony Affolder -->
<!-- Op5: &nbsp; -->
<!-- Op6: &nbsp; -->
<!-- Notes: -->
<pre>Plans: 
   continure testing in both sides 
    Noteht side cables 
    interlocks</pre>


<!-- Date: Sun Feb 25 08:27:52 2001 -->
<pre>messages from the intrerlock people yesterday 
 
Friday  from steve blusk: 
   I wanted to update you as to the status of the recent PLC woes we've 
been experiencing over the last 2 days. 
 
The initial problem we found is that two C-memory locations (bit 
memory) were being overwritten. Nowhere in the interlock code could we 
find that they were in fact being overwritten, or even written to. Of 
course this is troublesome because the software is clearly behaving in an 
unpredictable way. 
 
The problem appears to somehow be related to having too many special 
function programs (SFPGMs) in the queue. Some of the SFPGMs are long, and 
trying to execute them with the frequency which we were asking may have 
been a problem. The overwrites were typically accompanied by a non-fatal 
error in Status word #162 (STW162) ["cyclic SFPGM overrun error"]. While 
not fatal, this clearly pointed to some problem.  
 
We switched several of the SFPGMs to execute less frequently (say every 
1 or 2 seconds or more), and now the Interlock code seems to be running 
reliably and w/o the STW162 error. We plan to add some type of alarm on 
STW162, as this potentially points to a serious problem. 
 
It's not clear why this problem emerged now. We hadn't seen it up until 
now. However, for B4, we were not executing many of these LONG SFPGMs. The 
B4 ones were usually shorter. 
 
Anyway, we will keep our eye out for this problem, and add some type of 
warning for it which will be broadcasted to iFix. 
 
Saturday 
 
 
   A bit more probelms. It appears that the overwriting is 
probably due to "dummy variables" being used in more than 1 SFPGM. 
It appears that the processor can exit one SFPGM, execute another, 
and then return to the original. If there are common dummy variables in 
both, this could reek havoc in various loops. 
We tested this with one particularly strange overwrite, and it 
went away after making this change. Mircea is going to make all the dummy 
variables unique in all SFPGM's, and we'll go from there. We'll also 
follow up with Siemens to try and confirm this, and see what variables we 
can interlock on to make sure it's not occurring. 
 
Regarding the 5V enables, we tested the south side ones and they are all 
correct. For ISL, you should use the first 3 enables. We'll have to make 
sure that the proper PS's are daisy-chained to each enable. 
 
 
</pre>
<!-- Author: Jean -->


<!-- Date: Sun Feb 25 11:48:03 2001 -->
<pre>Tested SVX B2 W7 bundle. Voltages OK, but OFTM pipe 9 has problems. Verified that it is the OFTM by swapping doims at face and at OFTM. 
 
</pre>
<!-- Author: David Tony Tim -->


<!-- Date: Sun Feb 25 12:51:32 2001 -->
<pre>Probed ISL B2W0 and ISL B2W1. Both have bias splitting set for a forward barrel (even numbered layers have -HV shorted to HVref), but they are supposed to be for the central barrel which has all bias symmetrically split. These need to be swapped with B1W3 and B1W5 which are wrong in the opposite direction.</pre>
<!-- Author: David, Tony, Tim -->


<!-- Date: Sun Feb 25 13:58:15 2001 -->
<pre>   So our test of making all "dummy variables" in SFPGM's unique to 
the given SFPGM seems to have solved the problem with overwring memory 
locations. I think we should still proceed cautiously with this since it 
is potentially a very dangerous problem. 
 
Here's what appeared to be the problem: 
 Dummy variables were generally used as "loop variables" in SFPGMs and 
were used to access and write to various memory locations. It looks like 
the processor permits one to leave a SFPGM (say SFPGM#1), execute SPFPGM 
#2, and return and finish up SFPGM#1. Since these loop counters were used  
in more than one SFPGM, when the processor returns to #1, it could have 
the loop counter different than what it should be.  
 
(SFPGM = Special function program) 
 
Here's how I suggest we proceed: 
 
1. Mircea and Andy should make sure that all loop variables are used in 
   one and only one SFPGM. Also, it should NOT be used in the ladder logic 
   either, as this could also cause an overwrite. 
 
2. After finshing with #1, Mircea and Andy should begin the validation 
   procedure. 
 
3. On Monday/Tuesday, Andy will try to contact Seimens and verify that 
   these overwrites can occur as I described above. Also, we should  
   check if there is any way the PLC can recognze this error condition, 
   or is it just purely self-administrative. My guess is that's it's the 
   latter, because the PLC does not know what we intend to do. 
 
4. We should set an iFix alarm for "cyclic SFPGM overrruns" (in STW162, 
   bit 8). 
 
5. I am carrying Jeff's cell-phone in case of an emergency. The 
   phone number is (630) 569-2916. If I do not answer or call back 
   immediately, it could be because I'm giving a talk. The hotel 
   I'm staying at is the Holiday Inn. The number is  1-800-733-3211. 
   I should be back by Wednesday afternoon, around 12:30 pm. 
 
I will call in and check with Mircea and Andy to see how it is going 
on Sunday, Monday and Tuesday night. 
 
 
 
Some miscellaneous items: 
 
1. The ISL chiller temp. control should be checked. It was set to 
   8C, and it cooled down to 2C? The LED on the chiller confirmed 
   the setpoint which we loaded, but the chiller went down to 2C ? 
 
2. The activation of the conductivity control for ISL system is pointing 
   to the wrong C-memory location so that when you go into AUTO, it does 
   not activate the control loop in the PLC. 
 
 
</pre>
<!-- Author: Steve blusk -->


<!-- Date: Mon Feb 26 03:59:24 2001 -->
<p> 
More news from interlock land:</p> 
<p> 
Mircea has gone through the interlock validation procedure for SVX and ISL.  I made a second pass through the ISL code being as anal-retentive as I possibly could and uncovered a couple things that ought to be added.  We'll do this tomorrow and we also want to carefully double-check the ISL RTD mappings in the code (a real headache).  After this I'm ready to give my blessing (and Steve's, by pre-arranged proxy) for the ISL interlocks.  Then I want to make a similar second pass through the SVX code.  The bottom line is I think the ISL will be ready by Monday afternoon and SVX by late in the evening.  I hope everyone is in agreement, though, that a careful, thorough interlock check-out that lasts a day longer is preferable to a quick, cursory check-out that could compromise the safety of the silicon.</p>  
<!-- Author: Andy Hocker -->


<!-- Date: Mon Feb 26 12:19:50 2001 -->
<pre>WiB #2 has problem with layer4 that initializes  
but does not end data back. Suspect a bad connection,  
I'll look at it. 
 
Load box for SVX has no connection for testing Bias and "DB ref". 
should it still be used ? Probably not ! 
 
SB3W8 tested OK (DB test need to be done).</pre>
<!-- Author: S. D&#39;Auria -->
<!-- Comment: Mon Feb 26 13;11;31 comment by...Petra and Saverio -->
<pre>DB test done. OK</pre>
<!-- Date: Mon Feb 26 12:21:01 2001 -->
<pre>PS GUI updates the status page from a differnt PS  
than the selected one. Experts called.</pre>
<!-- Author: Saverio -->
<!-- Comment: Mon Feb 26 13;25;27 comment by...Sav -->
<pre>Andrew fixed the problem, 
but GUI needs to be recompiled before using</pre>
<!-- Date: Mon Feb 26 12:22:32 2001 -->
<pre>East Bore emptied from equipment to close plug.</pre>
<!-- Author: Mary and Saverio -->




<!-- Date: Mon Feb 26 13:37:32 2001 -->
<pre>Who modified 'PS.conf' in /cdf/people2/svxii/daq/PSWest ? 
You are trying to run the PS GUI with incorrectly modified 'PS.conf". It should be : 
$CAENCONTROL_DIR 
LOGGING_OFF 
$CAENCONTROL_DIR/log 
svxinter.fnal.gov 
/cdf/people2/svxii/daq/PSWest 
The last line and the first line are switched in the file. 
The same for PSEast.</pre>
<!-- Author: Andrew -->


<!-- Date: Mon Feb 26 18:18:56 2001 -->
Replaced FTMs: 
<ul>  
<li> f120-f130 SVSWT b0fib01 Slot 10 S/N 126 PREP 563547 with 
S/N 143 PREP 565892  
<li> f140-f150 SVSWT b0fib01 Slot 11 S/N 103 PREP 564054 with S/N 159 PREP 565880 
</ul> 
<B> Please test these ISL "wedges"</B>
<!-- Author: SCN -->


<!-- Date: Mon Feb 26 23:56:22 2001 -->
<pre>Cabled the NW bottom rack: plugged the FIB/DOIMs in.  
Attention: one "FIB" cable was a remote sense, this is now  
loosely attached to the PS crate, it still has to be  
swapped with the real FIB cable of that wedge. I couldn't  
reach the PS cable bundle... 
 
I also disentangled the SVX FIB and DOIM cables. Many were  
not in a good shape (many kinks, FIBs trapped in DOIM  
bundles etc.) </pre>
<!-- Author: Petra -->
<!-- Comment: Wed Feb 28 07;18;00 comment by...SCN -->
<ul>
<li> I pulled out the bundle which had the Timing and Remote
Sense cables swapped and unswapped them, then redressed the bundle
<li> I also redressed all the DOIM and Timing cables
since they were not well protected.  Next time I suggest:
<ul>
<li> Keeping careful seperation of the DOIMs and Timing cables 
based on which type they are, where they go, and how they
leave the cable tray
<li> Dressing the slack (or at least making sure we know how
to do it) before plugging in
</ul>
</li>
</ul>

<!-- Date: Tue Feb 27 00:59:27 2001 -->
<pre>WE finished our shift and here are the conclusion: 
No more work to be done on: 
ISLB1W5, L00B0W2, L00B0W3, ISLB1W4, ISLB1W2 
 
</pre>
<!-- Author: GINO and LESTER -->


<!-- Date: Tue Feb 27 11:18:20 2001 -->
<pre>To replace the broken DOIM cable on ISL B0W3 layer3, we swapped over the unused layer 4 DOIM cable from a nearby L00 FIB (L00 B0W3).  
 
LD4FB0W3-066 <-> ID3FB0W3-089 
 
The L00 DOIM cable is relabelled at both ends</pre>
<!-- Author: David Stuart -->


<!-- Date: Tue Feb 27 12:19:10 2001 -->
<pre> Tue, 27 Feb 2001 00:39:36 -0600 
 
       I started to revalidate the interlock code(following the 
procedures I wrote) after the discussion with Siemens technician and the 
changes of SFPGM execution mode from cyclic to normal inline and I haven't 
found any more bugs or something suspect in the code. I still think a 
code reading is very useful and Andy will help me to do this. 
        I revalidated two thirds of the code(in fact the last one third 
it was partially  checked on Sunday and the changes we made in the code 
are minor) and  Andy and I will do the remaining tomorrow. 
        Regarding a concern Steve had about executing all the SFPGM 
inline, I've checked with Andy if the RTD modules get initialized in a 
right way every time we download new temperature limits and we had no any 
failure in quite a lots of trials(we reinitialized all the modules about 
50 times). 
        The time for one scan can also be seen in IFix, on "PLC status" 
page.I tried to monitor this time and it was very stable, around 
134 ms. Also it could be useful to display possible PLC errors on IFix PLC 
status page. 
</pre>
<!-- Author: Mircea Coca -->


<!-- Date: Tue Feb 27 12:22:22 2001 -->
<pre> both west nigtrogen lines and isl east nitrogen have been flushed 
  (they took the filter when they went to install the bpipe yesterday... 
  i've not been able to track it down to flush svx east).  i've  
  connected the ISL nitrogen lines east and west and am flowing to the 
  detector at about 25 scfh/end.  i attached signs to the gas rack 
  asking that the isl lines be left as is. 
 
  i will leave it to brenna's descretion as to when she'd like to  
  attach the svx lines.  i've presently set those lines to 40 scfh each 
  and just have them sticking in the end of the detector.  we should 
  leave those flowing since they are "T"d for use by the WIBs. 
 
  presently, we're not operating anywhere near the dp.  we should only 
  ensure the N2 lines are connected to svx prior to the installation of 
  the cot baggy - which i guess will take place in mid-march. 
 
</pre>
<!-- Author: Doug G. -->


<!-- Date: Tue Feb 27 12:24:22 2001 -->
<pre>There is the potential for confusion about which of the two ISL biases  
is which. Tony and I figured it out today and here is our conclusion. 
 
The GUI calls them Bias0 and Bias1. The cables are labelled B1 and B2. The 
power supply calls them OUTC and OUTD (left and right). The long junction 
card calls them J4 and J5. The short junction card calls them J6 and J7. 
The portcard calls them SVX and ISL (or thumb) bias. The gangcard calls 
them HV1 and HV2. I call them fu and bar. 
 
The following are the synonyms. 
 
 HV1 = SVX = J6 = J4 == B1 === OUTC ==== Bias1 
 
 HV2 = ISL/Thumb = J7 = J5 == B2 === OUTD ==== Bias0 
 
where 
  = means hardwired in the detector. 
  == means the way the cables are supposed to be connected to the junction card 
  === means the way the cables are supposed to be connected to the power supply 
  ==== means the current GUI mapping, but since this is backwards, it could 
       eventually be discovered and "fixed" without warning. I'll talk to 
       the PS guys about this. 
 
Until further notice, we should use this decoding. 
</pre>
<!-- Author: Dave Stuart -->


<!-- Date: Tue Feb 27 14:01:41 2001 -->
<pre>West beampipe installation started. It is expected to take 1 hour. We decided to wait out the hour rather than trying to setup and test on the east since we are nearly done with the south west. 
 
</pre>
<!-- Author: David Stuart -->


<!-- Date: Tue Feb 27 15:29:47 2001 -->
<pre>West beampipe installation finished.</pre>
<!-- Author: DS -->


<!-- Date: Tue Feb 27 20:21:28 2001 -->
<pre>Retested on EAST Side the  
SVX CHANNEL B3W5 
 
(we reconnect the interlock cable on the SE crate 14) 
 
RESULTS: 
READY TO GO 
 
TEST FILE: laser29.svx 
 
NOTE: pay attention to the layer 4 device of the east WIB 
because of init. problems (readback 55 instead of 56 at the  
very beginning)</pre>
<!-- Author: SDA & FP -->


<!-- Date: Wed Feb 28 00:05:49 2001 -->
<pre>we tested the last two bundles 'to be retested'  
on the south west side (SB2W7,IB1W2) and finished SB2W4. 
All passed the test. 
Then we moved on to the north side for the first time and  
tested (under big headaches - see specific logbook entry)  
IB2W2, and it passed the test.</pre>
<!-- Author: Gino,Peta -->


<!-- Date: Wed Feb 28 02:33:21 2001 -->
<p>SVX and ISL interlock check-out is COMPLETE.</p> 
<p>Except....</p> 
<p>We got stuck on one small issue -- Layer 00 RTDs.  We confirmed that they disable power supplies correctly when above a trip limit, but the problem is that there are RTDs for the silicon and RTDs for the hybrids and they each have their own default trip limits.  Unfortunately, the 16 L00 RTDs were given the oh-so-descriptive names of "L00-R-01," "L00-R-02," etc. so we can't be certain that each RTD has the correct silicon-or-hybrid default trip limits.  I've searched high and low for a document with the mapping spelled out and called everyone associated with L00 I can think of and came up empty-handed.  I repeat, though, that the L00 RTD interlocks do function correctly.</p> 
<p>I don't know if this will delay us getting pORC'ed tomorrow or not... sorry.</p>
<!-- Author: Andy and Mircea -->
<!-- Comment: Wed Feb 28 07;19;27 comment by...SCN -->
<pre>You called everyone yopu could think of at 02:33:21?  Brave soul...</pre>


<!-- Date: Wed Feb 28 07:59:35 2001 -->
If you need them, here they are 
 
<ul> 
<li> <A HREF="ftp://www-cdfonline.fnal.gov/pub/cdfvme/cstep.ftm">cstep.ftm</A></LI> 
 
<li> <A HREF="ftp://www-cdfonline.fnal.gov/pub/cdfvme/layer_0.svx">layer_0.svx</A></LI> 
<li> <A HREF="ftp://www-cdfonline.fnal.gov/pub/cdfvme/layer_1.svx">layer_1.svx</A></LI> 
<li> <A HREF="ftp://www-cdfonline.fnal.gov/pub/cdfvme/layer_2.svx">layer_2.svx</A></LI> 
<li> <A HREF="ftp://www-cdfonline.fnal.gov/pub/cdfvme/layer_3.svx">layer_3.svx</A></LI> 
<li> <A HREF="ftp://www-cdfonline.fnal.gov/pub/cdfvme/layer_4.svx">layer_4.svx</A></LI> 
 
</ul>
<!-- Author: SCN -->


<!-- Date: Wed Feb 28 17:38:46 2001 -->
<pre>SB3W4 -- Suspect Fib cable problems, could not get 'scope to 
         check this. 
SB4W7 -- Orange cable channel 3 reported broken  
         (and verified). Otherwise ok 
SB5W7 -- Bias voltage on ch.3 draws no current, suspect cable. 
         We had to leave the bore at this point (3.30 pm)</pre>
<!-- Author: Saverio and Francesco -->


<!-- Date: Wed Feb 28 17:48:41 2001 -->
<pre>ISL B0W3 plugged and tested to detector.   
Everything works.</pre>
<!-- Author: D. Stuart and A. Affolder -->


<!-- Date: Wed Feb 28 18:46:31 2001 -->
<pre>Power supply installation, replacements and repairs 
 
Replaced 
 
Replaced IB0W2 in SW Top lower crate slot 3.   
  PS 22 replaced with 33 
 
Installed 
PS SVX 21 in LB0W5-127 NW Bottom upper crate slot 1 
PS SVX 45 in LB0W0-045 NW Bottom upper crate slot 5 
PS SVX 58 in LB0W4-107 NW Bottom lower crate slot 1 
PS SVX 33 in LB0W1-028 NW Bottom lower crate slot 9 
PS ISL 10 in IB2W2-113 NW Bottom upper crate slot 9 
 
Repairs 
 
PS 73 that had DVDD2-DVDD3 short is fixed. 
 
 
 
 
 
</pre>
<!-- Author: herndon -->


<!-- Date: Thu Mar 1 13:30:00 2001 -->
Finished checklist for connection of IB0W3 is 
<A HREF="http://ncdf17.fnal.gov/cgi-bin/lgbk?user=stuart&ent=10736"> here</A>.
<!-- Author: David Stuart -->


<!-- Date: Thu Mar 1 14:39:09 2001 -->
<p>A change was made to the silicon interlock code - The hardcoded SVX-II temperature limit and maximum SVX-II port card settable temperature limit was changed from 17 and 15 degrees C, respectively, to 25 degrees C.</p> 
 
<p>This change was made in accordance with CDF procedure 110.</p>
<!-- Author: Andy Hocker, Steve Blusk -->
<!-- Comment: Thu Mar  1 14;48;25 comment by...Petra -->
<pre>We had frequent trips while testing SB2W8 for plugging it in.
Seems to be stable now with new temperature settings.</pre>


<!-- Date: Thu Mar 1 21:27:59 2001 -->
<pre>We connected and tested L00 junction card for B0W3 
We encountered two problems.  
 
   - All HDIs ended their data with d0. We recalled seeing 
     this previously being caused by chip id values (changing 
     from 80 to a0 caused it in the past). So, we changed the 
     ids from 80 to a0 to see if that would fix it. It did. 
 
   - The last HDI had somewhat random bit errors. 
     Coupled with the fact that the 2V doim current was high 
     (1000mA instead of the usual 700mA), we suspected that the 
     power supplies had the DOIM voltages set to SVXII settings 
     which was driving too much light. We removed the optical 
     grease and separated the DOIM connectors just a little. 
     Then there were no errors. 
 
With these fixes, the data looks very similar to the last test done at SiDet.</pre>
<!-- Author: David Chris Auke-Pieter Tim -->
<!-- Comment: Fri Mar  2 07;55;34 comment by...SCN -->
<pre>Yeah, my fault.  I'll get those files changed today.
L00 is the exception to the rule (surprise surprise) that
all LastChipIDs = 32, meaning a Z side chip, since L00
has no Z side.</pre>
<!-- Date: Thu Mar 1 22:49:23 2001 -->
<p> 
We had two chiller interlock trips today.  The first was around 2 pm.  It was caused by people working under the detector and bumping some drain valves on an SVX line open.  This caused the pressure in the air separator to get too high and so the SVX chiller turned itself off.</p> 
 
<p> 
The second trip was the ISL chiller.  It has been acting strangely, making wide excursions beyond its set point.  Steve B. and I investigated today and saw that its control loop alogrithm and parameters are wrong.  Or at least they're completely different from what SVX's are.  We will ask Jim and/or Stanek to have a look at this tomorrow.  Anyway, around 8:30 pm one if its downward excursions brought its temperature too close to the freezing point and the chiller's internal freeze control shut down its compressor, triggering the interlock.  After it warmed up it self-recovered.</p>  
<!-- Author: Andy H. -->


<!-- Date: Fri Mar 2 04:23:37 2001 -->
<pre>Connected and tested ISL JC for In3 (B1W3). Looks fine, but progress was slow due to cooling problems.</pre>
<!-- Author: David and Auke-Pieter -->



<!-- Date: Fri Mar 2 12:48:19 2001 -->
<p> I'm trying to keep up with logging all the interlock trips...</p> 
 
<p> I heard from Petra via Doug that last night during the wee hours there was an ISL trip that also tripped SVX.  I don't know the details, but it could've been an ISL temp going above 17 degrees, which cuts the power to all the 5V enables.</p> 
 
<p> Around 11:00 this morning all the supply valves shut.  Jim E. wandered by an iFix machine and noticed this and turned them all back on.  There were no flow enable trips flashing, so maybe someone shut them manually?  Could also be a PLC glitch -- that interlock self-acknowledges, turning the flow enables green again possibly before anyone noticed.</p>  
<!-- Author: Andy Hocker -->


<!-- Date: Fri Mar 2 18:05:38 2001 -->
<pre> I reset the bias on the 18 SVXII power supplies on the southwest 
quadrant of the detector.  I also set the current sensitivity 
jumpers to the 5mA scale for the micron layers(2 and 4). 
 
 
 I reset the bias and DOIM low voltages on the southwest and 
northwest L00 supplies. 
 
  I used these values. 
 
SVXII 
Layer 0 170V 
Layer 1 170V 
Layer 2 60V 
Layer 3 140V 
Layer 4 60V 
 
L00 
Layer 0     90V 
Layer 1     90V 
Layer 2     90V 
Layer 3     160V 
Layer 4(3b) 160V 
2V DOIM 2.0V 
5V DOIM 5.0V 
 
  The behavior of the detectors with these settings is as 
follows.  If you set the bias voltage to the above values it does 
not trip.  If you set the  bias voltage 1V higher most layers 
trip.  If you set the voltage 2V higher all but a few percent 
trip.  All detectors trip when set to 4V higher than the above 
value.  This odd behavior seemed to be concentrated in layer 1. 
I assumed that this was not a problem since we had already 
taken 10V off the burn-in value. 
</pre>
<!-- Author: herndon -->


<!-- Date: Fri Mar 2 18:10:19 2001 -->
<pre>Enables! 
 
I'd like to explain the use of the enable system at the power 
supply.  The enables from the interlock system connect to a 
daisy chain of T connectors located just under the power 
supplies. The connection of various power supplies to the 
correct enable is done using this daisy chain.  To connect 
an individual power supply a lemo cable should be run from the 
T connecter directly below the supply to the supply enable 
connector.  Running to adjacent supplies can result in the 
wrong set of interlocks being connected. 
 
  - matt</pre>
<!-- Author: herndon -->


<!-- Date: Sat Mar 3 05:45:37 2001 -->
<pre>Found a bad OFTM at b0fib02 slot 13 channel 9 
while WIB testing SB1W7. We took the OFTM from  
slot 10 of b0fib07 (an uncabled NE bottom rack  
part) as a spare and are replacing 
the bad OFTM with it.</pre>
<!-- Author: Andy Foland, Lester -->


<!-- Date: Sat Mar 3 17:25:01 2001 -->
<p> 
Silicon interlock code changed according to CDF procedure 110 in order to allow ISL temps up to 25 deg C. 
</p> 
  
<!-- Author: Andy Hocker -->


<!-- Date: Sun Mar 4 00:37:37 2001 -->
<pre>Connected and tested ISL B2W1 (aka W6C1). It tested good. 
</pre>
<!-- Author: David and Franz -->


<!-- Date: Sun Mar 4 00:40:39 2001 -->
<pre>Retested L00 B0W3 after power supply DOIM settings fixed. 
We first tested the ps with a different cable bundle and the load box. It was fine. Then we tested it with the detector and it tripped on bias over current. We retreated to the test with the other cable bundle. It still tripped. 
 
Tonight we retested and there were no trip problems. But, when we reconnected to the detector, the low voltages where screwed up. Traced this to a bad sense cable connection. Reseating it fixed the problem. We tried to redress the cables to reduce the strain and this made the problem come and go. Tomorrow we should nail the connector in place with 5-min. 
 
</pre>
<!-- Author: David and Franz -->


<!-- Date: Sun Mar 4 03:32:04 2001 -->
<pre>Plugged E6C1 (ISL B3W1). Tests ok. 
</pre>
<!-- Author: David and Franz -->


<!-- Date: Sun Mar 4 08:10:03 2001 -->
<pre>SB2W6 plugged in. Everything went quite smoothly, readout correct. 
We experienced one interlock problem originating from L00,  
solved with the intervention of Andy by thelephone. 
COT dew point went off on both sides (east&West). 
  
</pre>
<!-- Author: Andy Foland and Saverio -->
<!-- Comment: Mon Mar  5 11;30;25 comment by...Petra and Saverio -->
<pre>Also SB1W6 was plugged in smoothly, readout correct.</pre>
<!-- Date: Sun Mar 4 12:52:42 2001 -->
<pre>tested the last possible SVX wedge B0W6 and plugged it in. 
everything but a few RO errors on L4 was fine. 
next step would be adjustment of DVDD4 on PS. 
 
This was the last test for a while on the WEST side.</pre>
<!-- Author: Lester, Petra -->


<!-- Date: Sun Mar 4 15:19:08 2001 -->
<pre>Plugged L00 B1W3 on east side. HDI 3 won't init. We suspect DOIM or OFTM problems, but we can't investigate due to time  and because the DAQ won't take any data on the east L00. 
 
</pre>
<!-- Author: David and Tony -->
<!-- Comment: Tue Mar  6 11;54;30 comment by...SCN -->
"DAQ won't take L00 data" is misleading.  There is nothing
wrong with the DAQ, just a <a href=
'/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=9&frame=2&anchor=11:26:43'>
configuation issue</a> since it was decided to concentrate on the
West side.
<!-- Date: Sun Mar 4 15:21:43 2001 -->
<pre>We retested the west L00 after SVXII plugging finished on the west. Now the power supply won't turn on due to 5VDOIM overcurrent trips. 
 
We can't see if there is a problem on the junction card because it is now covered by an SVXII junction card. 
 
</pre>
<!-- Author: David and Tim -->
<!-- Comment: Tue Mar  6 16;56;02 comment by...Jean -->
<pre>L003=B0W3 </pre>
<!-- Date: Sun Mar 4 17:45:13 2001 -->
<pre>The ISL chiller was turned off due to instability of the temperature control circuit. The problem will be addressed on monday and the system will 
be brought back up.</pre>
<!-- Author: Rich Stanek -->


<!-- Date: Sun Mar 4 17:48:14 2001 -->
<p> 
ISL chiller powered off locally -- its hot gas solenoid 
valve is faulty and causes it to go to too low a temperature.  If the valve isn't easily fixable we can switch to the spare chiller.</p>  
<!-- Author: Andy Hocker -->




<!-- Date: Tue Mar 6 16:20:13 2001 -->
Testing Fib-Vrb links: 
<ul> 
<li> SVNET (b0fib00) looks ok <BR> 
<li> SVNEB (b0fib03) 
<ul> 
<li>Slot 9 - 1RR21B (b0svx08) slot 8 <B> READ BUSY </B> probably 
means VTM is not plugged in? 
<li> Slot 10 - 1RR21B (b0svx08) Slot 15- Chan 1 bit Error: 
<pre> 
Error Loop # 1 buff 0 VCh 1 index 330   Expect: 0xffe08444 Receive: 0xdfc08444 
Error Loop # 1 buff 0 VCh 1 index 331   Expect: 0x007e017d Receive: 0x005e015d 
Error Loop # 1 buff 0 VCh 1 index 332   Expect: 0x027c037b Receive: 0x025c035b 
Error Loop # 1 buff 0 VCh 1 index 333   Expect: 0x047a0579 Receive: 0x045a0559 
... 
Bit/Chan   0     1     2     3     4     5     6     7     8     9   
    0        0     0     0     0     0     0     0     0     0     0 
    1        0     0     0     0     0     0     0     0     0     0 
    2        0     0     0     0     0     0     0     0     0     0 
    3        0     0     0     0     0     0     0     0     0     0 
    4        0     0     0     0     0     0     0     0     0     0 
    5        0    90     0     0     0     0     0     0     0     0 
    6        0     0     0     0     0     0     0     0     0     0 
    7        0     0     0     0     0     0     0     0     0     0 
    8        0     0     0     0     0     0     0     0     0     0 
    9        0     0     0     0     0     0     0     0     0     0 
   10        0     0     0     0     0     0     0     0     0     0 
   11        0     0     0     0     0     0     0     0     0     0 
   12        0     0     0     0     0     0     0     0     0     0 
   13        0     0     0     0     0     0     0     0     0     0 
   14        0     0     0     0     0     0     0     0     0     0 
   15        0     0     0     0     0     0     0     0     0     0 
   16        0     0     0     0     0     0     0     0     0     0 
   17        0     0     0     0     0     0     0     0     0     0 
   18        0     0     0     0     0     0     0     0     0     0 
   19        0     0     0     0     0     0     0     0     0     0 
   20        0     0     0     0     0     0     0     0     0     0 
   21        0   100     0     0     0     0     0     0     0     0 
   22        0     0     0     0     0     0     0     0     0     0 
   23        0     0     0     0     0     0     0     0     0     0 
   24        0     0     0     0     0     0     0     0     0     0 
   25        0     0     0     0     0     0     0     0     0     0 
   26        0     0     0     0     0     0     0     0     0     0 
   27        0     0     0     0     0     0     0     0     0     0 
   28        0     0     0     0     0     0     0     0     0     0 
   29        0    10     0     0     0     0     0     0     0     0 
   30        0     0     0     0     0     0     0     0     0     0 
   31        0     0     0     0     0     0     0     0     0     0 
</pre> 
Will check if VRB/VTM or Fib... 
<li> L00 chip info looks absent (at least on laptop) 
</UL> 
<li> SVNET (b0fib04) VME Power is off (forgot to turn it on 
after cabling the rack...will fix at access time).  Also no VTMs 
plugged in yet... 
<li> SVNEB (b0fib07) No VTMs plugged in- scheduled for tomorrow 
morning 
</ul> 
In addition, due to a fan failure on SVSWB (b0fib02) that does not recover when being reset, that crate is off until we can 
access it and see what is wrong. 
  
<!-- Author: SCN -->
<!-- Comment: Tue Mar  6 16;21;12 comment by...SCN -->
<pre>SVNET (b0fib00) should be SVNWT
SVNEB (b0fib03) should be SVNWB</pre>


<!-- Date: Tue Mar 6 16:54:12 2001 -->
<pre>SVNEB L00 Chip Info is now present.</pre>
<!-- Author: SCN -->