<!-- Title: 17:16:07  Tue Jan 22 2002 -->
<!-- Crewchief: silipeople -->
<!-- Op1: &nbsp; -->
<!-- Op2: &nbsp; -->
<!-- Op3: &nbsp; -->
<!-- Op4: &nbsp; -->
<!-- Op5: &nbsp; -->
<!-- Op6: &nbsp; -->
<!-- Notes: -->
<pre>The old file was too long 
----------------------- 
 
Plan 
---- 
1. run this shot out 
2. studies days - wed and thurs 
    a. Lester - study various ladder problems 
    b. GUI upgrades/fixes - Doug b, Andrew 
    c. deadband for GUI spy 
    d. x-mode if steve wants 
    e. reformater errors if Steve, lester want to</pre>


<!-- Date: Tue Jan 22 19:48:39 2002 -->
<pre> 19:45:47 Started a new version of the Gui Spy with  
deadband of 0.05 uA on all bias currents. 
No report was lost. 
</pre>
<!-- Author: Saverio -->


<!-- Date: Tue Jan 22 20:28:29 2002 -->
Steve's analysis of reformater errors can be found 
<a href= 
'/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=93&frame=2&anchor=16:36:26'> 
Here </a>.   
<!-- Author: jean -->


<!-- Date: Wed Jan 23 02:23:11 2002 -->
<pre>SB5W2L2 DVDD over current trip. Resetting trip and PS: OFF--&gt;STANDBY--&gt;ON. </pre>
<!-- Author: aces -->


<!-- Date: Wed Jan 23 05:49:02 2002 -->
There is an option to unmark all the pinky boxes, so we can get <BR>an updated version of problematic channels. I tried using it <BR>twice, but the IMON hangs. Should we tried to separate the <BR>process in three: unmark SVX, unmark ISL and unmark L00? This <BR>option would be very useful. 
<BR> Also after a trip, a whole wedge is turn OFF. When turning <BR>it ON I would expect that all the pinkies to be "reseted" to <BR>green, but this doesn't happen. So one have to unmark one by <BR>one. Could this be fixed ?
<!-- Author: Mircea C -->
<!-- Comment: Wed Jan 23 17;52;15 comment by...Andy H. -->
<pre>"Unmark all" doesn't hang Imon, you just have to be patient.
Automatically unmarking pinkies after a trip means that if you
don't check Imon before you reset the trip, you lose what the
currents were just before the trip -- potentially useful info.</pre>
<!-- Date: Wed Jan 23 06:09:54 2002 -->
Another comment: I think that having somewhere in Silicon elog a <BR>list on known pinky channels, instead of the flying papers <BR>all around the Java gui will help monitoring ACE. And will <BR>give more sleep time to silicon pager ... 
<!-- Author: Mircea C -->


<!-- Date: Wed Jan 23 06:29:10 2002 -->
<pre>We had to put the Silicon in Standby...So we tried to to do this &lt;BR&gt;from the High Voltage Summary page. First thing I saw, the &lt;BR&gt;Standby boxes were showing that the system was already in &lt;BR&gt;Standby(light green color). This was clearly false. To be &lt;BR&gt;fixed. 
&lt;BR&gt;Second: Aftre we click on Standby for SVX, ISL and L00 GUI &lt;BR&gt;frozed, waited 5 minutes, High Voltage Summary showed that HV &lt;BR&gt;were still on ( green bars). No alarms on Global Alarm Page. 
&lt;BR&gt;Restarted the GUI Java, suddenly the HV Summary showed ISL &lt;BR&gt;and L00 in standby, but not SVX...Checked the GUI, SVX B1 W6 &lt;BR&gt;still on...Put it manually in Standby. 
&lt;BR&gt;Also got Software protection trip: High DVDD curent SVX B1 W1 &lt;BR&gt;L4 (twice, in 1 minute interval )... No clue why...  
&lt;BR&gt;I suspect SVX B1 W6 might have been turn on by GUI, believing &lt;BR&gt;should have been on, but got turned OFF...I saw a message &lt;BR&gt;along this lines on the xterm GUI was started from...Experts, &lt;BR&gt;could this be the cause?</pre>
<!-- Author: Mircea , Slava  -->


<!-- Date: Wed Jan 23 06:31:02 2002 -->
<pre>We had to put the Silicon in Standby...So we tried to to do this &lt;BR&gt;from the High Voltage Summary page. First thing I saw, the &lt;BR&gt;Standby boxes were showing that the system was already in &lt;BR&gt;Standby(light green color). This was clearly false. To be &lt;BR&gt;fixed. 
&lt;BR&gt;Second: Aftre we click on Standby for SVX, ISL and L00 GUI &lt;BR&gt;frozed, waited 5 minutes, High Voltage Summary showed that HV &lt;BR&gt;were still on ( green bars). No alarms on Global Alarm Page. 
&lt;BR&gt;Restarted the GUI Java, suddenly the HV Summary showed ISL &lt;BR&gt;and L00 in standby, but not SVX...Checked the GUI, SVX B1 W6 &lt;BR&gt;still on...Put it manually in Standby. 
&lt;BR&gt;Also got Software protection trip: High DVDD curent SVX B1 W1 &lt;BR&gt;L4 (twice, in 1 minute interval )... No clue why...  
&lt;BR&gt;I suspect SVX B1 W6 might have been turn on by GUI, believing &lt;BR&gt;should have been on, but got turned OFF...I saw a message &lt;BR&gt;along this lines on the xterm GUI was started from...Experts, &lt;BR&gt;could this be the cause?</pre>
<!-- Author: Mircea , Slava  -->
<!-- Comment: Wed Jan 23 17;45;51 comment by...Andy H. -->
<pre>The voltage status on the iFix HV summary page is represented by
the color of the bars and the status box (blue for STANDBY).  It
has nothing to do with whether the buttons are dark green or
light green.

If the GUI was really frozen for five minutes I find it odd that
there were no iFix alarms.  There is a 3-minute timeout.
</pre>
<!-- Date: Wed Jan 23 16:44:38 2002 -->
<table border=0><td><tr><td bgcolor=#e0e030><pre>Plan 
----- 
Thursday - 
    11:00 - Lester - problem ladders 
 
Other unscheduled activities: 
    1. Gui/IFIX work - Andrew, Doug B., Andy 
        needs quiet time or stable beam 
    2. access for L00 PS retrieval - Rob Napora</pre></td></tr></td></table>
<!-- Author: Jean -->




<!-- Date: Wed Jan 23 19:26:18 2002 -->
<b>Controlled Access</b> 
<p>Removed the two L00 flavor supplies from the collision hall and took them out of the CAEN map. 
<p>Attempted to power the silicon wedges I had to turn off back on and get the system through one iteration of cold start.  Could not get SB4W1L4 to initialize.  I then pestered Lester who had me mask the feedback for this channel in the HWDB (this layer's currents did look ok on the GUI).  Its FIB (FIB04) gets through cold start now. 
<p>I have declared victory and am going home.
<!-- Author: Napora -->


<!-- Date: Wed Jan 23 20:50:21 2002 -->
<pre>We tried an SVX calibration in the remaining quiet time but couldn't understand the GUI behavior: is it normal for the radio buttons to go BACK to standby while the ISL is turning on?  Anyway, we will try during more quiet time.</pre>
<!-- Author: ath,k giolo, as nicollerat -->


<!-- Date: Thu Jan 24 13:33:56 2002 -->
Matt suggested opening up some Fib Timing cables 
to see if there is a bad connection on the Fib side.  I just 
massacred a 40ft cable (not to be used in the experiment anyway) 
and decided that you may be able to see a very gross failure 
just by taking the cover off, but if you proceed further than 
that in disassmbling the connector, you will most likely 
make it irreparable and should be ready to reterminate it 
with a new connector, which looks difficult but not impossible 
if you have the parts and tools.
<!-- Author: SCN -->


<!-- Date: Thu Jan 24 14:53:07 2002 -->
<pre>Information form the SVT people: 
------------------------------------- 
I'm hoping this evening to implement (a) a timeout mechanism and (b) 
immunity to DRO (i.e. no H/R/R needed).  With luck, in another day or so 
we could also have (c) ability to propagate timeout to an error bit for 
diagnostic spy buffer readout and (d) a hardware measurement of average 
timing and rate of DRO per ladder. 
 
I think Marco is also thinking about a software measurement of the 
per-ladder timing distribution, based on the number of words each Hit 
Finder writes for each ladder to its input spy buffer (which is 
essentially a G-link logic analyzer built into the board). 
 
The long times definitely come from the 1/3 of the detector that SVT calls 
Wedges 4-7 (i.e. SB[0-5]W[4-7]), and could be narrowed down further with a 
special run, but since this problem has come and gone in the past, it 
seemed more sensible to implement a way to address it without special 
runs. 
 
In other news, Marco has also done an analysis of many of the H/R/R needed 
during a run taken last weekend.  Here's what he found. 
 
The largest contribution to SVT H/R/R requests is DRO.  Here are some 
early statistics: 
 
  6 SB5W7L0 
  5 SB5W5L2 
  5 SB4W9L2 
  3 SB2W1L3 
  2 SB2W1L2 
  1 SB2W7L4 
  1 SB0W1L3 
 
G-link core dumps available on request.  Much more scary is that there is 
something that looks like G-link lost lock coming from SB2W7L[012].  If 
the VRB doesn't see this, I'd like to try swapping around VTMs or Hit 
Finders. 
 
And there are 7 examples of the bunch ID following the pattern A,B,C,C,E,F 
instead of A,B,C,D,E,F, i.e. one event has wrong BC (a copy of the 
previous BC) but the sequence is otherwise fine.  This happens only on 
SB2WAL2. 
 
 
I see 7 repeated BC in SB2WAL2, leaving only b0svt05_20020120095505.dat 
unexplained.  I hope swapping out that FIB would be adequate to fix that. 
Meanwhile, I guess we can mask LS in that stream and live with a low rate 
of errors from the cases in which it is the first stream to finish. 
 
We should definitely correlate these with the SVX people. 
 
</pre>
<!-- Author: email from Billa, jean -->


<!-- Date: Thu Jan 24 16:19:37 2002 -->
<h3>Downloading Pedestals and Thresholds</h3> 
Due to recent interest, we revived the old Broker mechanism 
for downloading pedestals and thresholds to the  
Fibs/Chips.  I just took a few runs (137682-137684) with 
the correct valid set 58715 but the Si was at Standby, so 
the pedestal subtraction part won't be really correct 
nor the thresholds, though one should be able to see killed channels.  I think it would be nice to process these runs  
just to see what we get and if it makes sense.  
<!-- Author: SCN -->
<!-- Comment: Tue Jan 29 13;05;51 comment by...SCN -->
Oops.  that's Runs 137862-137864.  Sorry for the dyslexia.
<!-- Date: Thu Jan 24 19:51:36 2002 -->
<pre>A new spy program is running: 
ps_test.exe 
This process listen to smartsockets messages that the new 
version of the PS GUI sends. These messages contain 
information on time and channels that are spontaneusly  
switched to a different state by PS.  
This usually happens during global turn on or stand-by or off. 
Data are reported in  
 
/cdf/svx-data1/datalog/ps/ps_check.log 
 
Here is an example: 
01-24-2002 18:49:52 CST : 543806  SB5W8L3 status was found OFF should be STB GUI turned it to STB 
 
Andrew I., Doug B., Saverio D'A.</pre>
<!-- Author: Saverio -->


<!-- Date: Thu Jan 24 19:53:40 2002 -->
<pre>done silicon calibration.  
 
DPS on run 137884  
DPS off run 137885  
 
Silicon calibration failed. we forgot to press enter to switch to DPS off. we call the expert and we decided to take the calibration again. (we 
have time before the beam is on again). - K. Giolo, A. Holloway  
 
Silicon back to ON</pre>
<!-- Author: entered by Sav -->


<!-- Date: Fri Jan 25 07:50:46 2002 -->
<pre>Thu Jan 24 20:10:25  
 
done silicon calibration  
 
DPS on run 137894  
DPS off run 137895  
 
Now silicon on standby 
 
 - K. Giolo, A. Holloway :: (run 137895) </pre>
<!-- Author: entered by Sav -->


<!-- Date: Fri Jan 25 09:34:23 2002 -->
<pre>Something caused a LOT of software protection trips last night, 
what happened? 
 
This needs to be investigated. 
 
This is copied from the shift e-log: 
 
From 1.56.44 to 1.57.58 many layers of the silicon had:  
Software protection trip:high DVDD current.  
At 1.57.59 I had :TRIP SVX B5 W0 DVDD0 Overcurrent  
and red alarm on global alarm page.  
Silicon expert paged and following layers put on standby:  
SB0W10 layers: 0,1,2,3,4  
SB0W11 layers: 0,2,3,4  
SB5W1 layers: 0,1,2,3,4  
IB0W5 layers: 0,1,2,3,4  
IB0W4 layers: 0,1,2,3,4  
IB4W4 layers: 0,2,4  
IB5W5 layers: 0,2,4  
IB5W2 la: 0,1,2,3,4  
IB5W3 la: 1,2,3,4  
Coldstart tried succesfully.  
No significant losses appeared on ACNET, but further checks because ACNET seems now to don't 
update. 
 
</pre>
<!-- Author: Chris Hill -->


<!-- Date: Fri Jan 25 15:17:52 2002 -->
<table border=0><td><tr><td bgcolor=#e0e030><p> 
Margherita just finished a version of the iFix HV page that has 
the silicon "ON" buttons enabled.  Since Steve N. is here to do a 
D-mode calib, we decided to try and bias the silicon from the 
iFix page.  IT WORKED!</p> 
<p>I'd like to exercise it a bit more, perhaps with 
Andrew I./Doug B. present as well -- then we can ask 
Margherita/J.C. to make this the official page that aces use.</p></td></tr></td></table>
<!-- Author: Andy H. -->


<!-- Date: Fri Jan 25 15:19:09 2002 -->
<pre>There was an external trip on SB4W6 2VDOIM that was more or less 
simultaneous with cold-starting the first D-mode calib.  We 
turned it back on and tried again.  OK now.</pre>
<!-- Author: Andy H., SCN -->


<!-- Date: Fri Jan 25 16:00:21 2002 -->
<pre>After calibs, we brought silicon to STBY by clicking the iFix 
STBY buttons for SVX/ISL/L00 bang-bang-bang, one after the other 
(the way the aces like to do).  For some reason, the L00 one 
didn't take the first time and we had to do it again.</pre>
<!-- Author: Andy H. -->


<!-- Date: Fri Jan 25 16:01:59 2002 -->
<pre>At 15:56 there was a software protection trip on SB5W4 L2 high 
DVDD current.  I turned it back to STBY (from the GUI).</pre>
<!-- Author: Andy H. -->


<!-- Date: Fri Jan 25 16:03:23 2002 -->
It has been quiet time for a several hours now, so I 
finally took it upon myself to take some calibrations (with 
Andy's help).<ul> 
<li>DMODE Runs 137947 (DPS OFF) 137949 (ON)  
<li>XMODE      137950 (DPS OFF) 137951 (ON) 
</ul> 
It turns out that if I stick the X Mode in the database right 
now, so that Level 3 and Stream A of production will have up to date pedestals (not to mention Fib Downloading...) it'll break the Used Set writer (for a bizaare reason, 
you really don't want to know) but in principle in the end 
that's what I'd do.  If I can fix it up in a short amount of 
time, that is what I will do.<P> 
10 minutes after ending all the Runs with the Silicon just 
sitting idle we got a <B>S</B>oftware <B>P</b>rotection <b>T</b>rip on SB5W4 L2.
<!-- Author: SCN -->
<!-- Comment: Fri Jan 25 18;03;56 comment by...SCN -->
Attempted to get this X Mode Cal into the DB, but failed
because it fails to get a Run Map for the previous FIB_PHYSICS_SVX Valid Set, which is Run number -1?
<pre>
 Found the previous ValidSet from DB ! 
  ValidSet : process FIB_PHYSICS_SVX
           : server DEPRECATED
           : jobset 60422
           : last run -1
</pre>
and the database queryer isn't working, so I cannot see what the
heck is going on.  Will make one more attempt...


<!-- Date: Fri Jan 25 22:35:59 2002 -->
<pre>svx08 rebooted (red on vxmon and unresponsive to rc transitions).</pre>
<!-- Author: Slava -->


<!-- Date: Sat Jan 26 09:54:01 2002 -->
<pre>There was a software protection trip on SB5W2 L2 high DVDD current.  Trigger inhibit was successfully set (note that 
the inhibit will not be cleared until "Reset Trips in CAEN" is 
clicked).  I turned the wedge back on.</pre>
<!-- Author: Andy H. -->
<!-- Comment: Sat Jan 26 19;34;14 comment by...Chris Hill -->
<pre>This was one to many trips for SB5W2L2, it and SB5W2L0 have been
taken out pending further investigation of the cause of the high
currents on DVDD.</pre>
<!-- Date: Sat Jan 26 12:14:42 2002 -->
<pre>As we were preparing to bring the silicon to STBY for the end 
of run 137994, several things happened in succesion. 
 
1) There was a trip on SB4W0 L4.  iFix tweeted, the GUI reported 
NOTHING.  IMON showed me where the trip was.  I turned this 
ladder back to STBY. 
 
2) Then, we ramped all silicon to STBY from the iFix page.  SB1W6 
remained ON.  I had to turn that one to STBY by hand. 
 
3) A few minutes later, there was another trip.  AGAIN, THE 
GUI REPORTED NOTHING.  However I saw the trip in the svxinter 
terminal was on B0W2 L0 -- when I brought up its full status 
it showed ExtTrip on DVDD.  Turned it to STBY, which cleared the 
trip.</pre>
<!-- Author: Andy H. -->


<!-- Date: Sat Jan 26 13:01:35 2002 -->
<pre>worked on b0puls01, to check the LED-powering DACs response to 
biassing. All the three DACs look good, with comparable current 
limits on their channels (of about 20 to 25 mA). </pre>
<!-- Author: diego cauz -->
<!-- Comment: Sat Jan 26 13;04;32 comment by...Andy H. -->
<pre>Ignore this entry -- it was meant for the CDF e-log.</pre>


<!-- Date: Sat Jan 26 16:54:50 2002 -->
<p> 
I made two changes to PSMon to keep it from generating false 
iFix alarms.  The first was to increase the timeout on waiting 
for the GUI to send an update message.  It will now wait for 
5 minutes before sounding an alarm (the previous 3-minute 
timeout just wasn't long enough when the GUI was busy trying 
to ramp all three detectors).</p> 
<p> 
I also disabled the alarm I had implemented that would trigger 
whenever a bias voltage was > Vset + 20 V.  This would always 
go off when we were ramping down.</p> 
<p> 
I'm hoping these changes will make the whole silicon powering 
experience less traumatic...</p>
<!-- Author: Andy H. -->


<!-- Date: Sat Jan 26 19:17:36 2002 -->
<pre>I confirm the problem noticed by Andy: 
- The GUI is not reporting the nature of the trip any more. 
- The GUI freezes for a very long time. 
- Bias trips on SBY-ON transition: 
 ISL B5W0L0 got a trip 
Sending Request for f500 
SVX B4W0L4 spontaneously turned on 
turning it back to standby 
checkSt[1][48][4] = 1 
SVX B4W0L4 spontaneously turned on 
turning it back to standby 
checkSt[1][48][4] = 2 
SVX B4W0L4 got a trip 
- we had to turn it back to SBY because of beam operations 
- SVX B3W11L4 got a trip on ON-SBY 
- ISL B2W1L0 Software protection trip on ON-SBY 
 
01-26-2002 19:03:51 CST : 717447  SB0W8L4 status was found OFF should be STB GUI turned it to STB 
 
01-26-2002 19:03:52 CST : 717447  SB1W1L4 status was found OFF should be STB GUI turned it to STB 
01-26-2002 19:03:52 CST : 717448  SB1W1L1 status was found OFF should be STB GUI turned it to STB 
01-26-2002 19:03:53 CST : 717449  SB4W10L0 status was found OFF should be STB GUI turned it to STB 
01-26-2002 19:03:54 CST : 717449  IB5W3L3 status was found ON should be STB GUI turned it to STB 
01-26-2002 19:03:54 CST : 717450  IB5W3L2 status was found ON should be STB GUI turned it to STB 
01-26-2002 19:03:55 CST : 717450  IB5W3L1 status was found ON should be STB GUI turned it to STB 
01-26-2002 19:03:56 CST : 717451  IB5W4L3 status was found ON should be STB GUI turned it to STB 
01-26-2002 19:03:56 CST : 717452  IB5W4L2 status was found ON should be STB GUI turned it to STB 
01-26-2002 19:03:57 CST : 717452  IB5W4L1 status was found ON should be STB GUI turned it to STB 
01-26-2002 19:03:57 CST : 717453  IB5W4L0 status was found ON should be STB GUI turned it to STB 
01-26-2002 19:03:58 CST : 717454  IB5W5L4 status was found ON should be STB GUI turned it to STB 
01-26-2002 19:03:59 CST : 717454  IB5W5L3 status was found ON should be STB GUI turned it to STB 
01-26-2002 19:03:59 CST : 717455  IB5W5L2 status was found ON should be STB GUI turned it to STB 
01-26-2002 19:04:00 CST : 717455  IB5W5L1 status was found ON should be STB GUI turned it to STB 
01-26-2002 19:04:00 CST : 717456  IB5W5L0 status was found ON should be STB GUI turned it to STB 
</pre>
<!-- Author: Saverio + David -->


<!-- Date: Sat Jan 26 19:18:37 2002 -->
<pre>SB4W0L4 looks unbiasable.</pre>
<!-- Author: Sav -->
<!-- Comment: Sat Jan 26 19;36;19 comment by...Chris Hill -->
<pre>This ladder will be taken out pending further investigation into
the large bias currents.</pre>


<!-- Date: Sat Jan 26 22:28:16 2002 -->
<P> 
Store 929 in with low and stable losses. After consulting with the silipager (Chris), we bias all the silicon.  
The iFIX HV summary page will not let us set the silicon on. So, we use the GUI. The global on button works, but it makes the GUI hang for about 5 minutes. Until this is fixed, it seems better to turn on one barrel at a time and wait at least 1 gui update between each barrel. 
<P> 
When the GUI finally unhangs, SB4W0L4 is off and gives an ifix alarm. The gui says nothing about it though. Try to turn it back to ON but it trips again--with no GUI statement. 
<P> 
While trying to figure out this latest GUI anomaly, the MCR calls and says they will turn on the TEL. This can generate high losses, so we set the silicon back to standby. 
This can be done using the iFIX HV summary page, but it takes a very long time and the GUI hangs. 
<P> 
We page silicon again about SB4W0L4. He says it has had this problem several times before so it should be taken out. He also said that SB5W2L0 and L2 should be taken out since they had more software trips this morning--the agreement with previous sci-co's had been to remove it if the problem continued. 
<P> 
SB2W1L3 spontaneously turned off. No notification (other than failed coldstart). Turned back on ok. 
<P> 
Finally got silicon biased. Run 138020 and following. Very clean beam. 
<P>
<!-- Author: David acting as CO -->
<!-- Comment: Mon Jan 28 09;12;52 comment by...SCN -->
Yes, Andy reinstalled the IFIX page with the
ability to turn on disabled, until we are sure everything
works to satisfaction.  It is the correct thing to do.
<!-- Date: Sun Jan 27 13:41:37 2002 -->
<pre>The PS GUI work: 
  Method of trip reporting has been modified so that the GUI  
doesn't require previous trip acknowledge before reporting the 
next trip. Trip acknowledge window is removed. All trips will be 
reported in the GUI display. The message contains time stamp, 
what ladder is tripped and the nature of the trip. In case of 
mysterious external trips, the cause of which, we don't 
understand yet, the GUI reports what power supply is tripped  
without specification of the nature of the trip and what channel 
is tripped. In this case go to full status window for details. </pre>
<!-- Author: Andrew & Doug -->



<!-- Date: Mon Jan 28 16:56:47 2002 -->
<pre>We have changed the silicon power supply server code so that 
the server code  does not automatically act on spontaneous 
standby -&gt; On and On -&gt; standby transitions. They are logged 
in the super secret silicon log file locations though.</pre>
<!-- Author: doug benjamin -->


<!-- Date: Mon Jan 28 22:36:31 2002 -->
<pre>I paid a little attention today to IMON and I did the following changes in the NOMINALS: 
 
Device   Current  Previous Nominal   Present nominal 
 
SB0W0L2  AVDD     415 mA             760 mA 
         One of the AVDD2 intermittent problem. 
         The current is now back in a state where all chips    
         should be initializing. 
         Looking at the file: 
/svx-data1/datalog/daq/20020128.si_daq 
         It did initialize correctly all day today. 
 
SB0W2L0  AVDD     110 mA             308 mA 
SB0W2L1  AVDD     336 mA             505 mA 
         These 2 are part of the wedge that we spotted changing  
         AVDD current in connection with HRR and other DAQ 
         activities.  
         It has been stable all day today and so I put everything 
         back to normal. 
 
As soon as we change the status from STDBY to ON I plan to change this other nominal (Unless I got to sleep) 
 
SB2W4L0  BIAS     500 uA          8 uA  
         I looked at this current vs time and I do not see why  
         the nominal should be so high. 
 
All this should get rid of some of the PINKS. 
 
I'm now left with a limited (5 SVXII 0 ISL and 0 L00) PINKs 
Here is the list and comments: 
 
device   current   nominal   reading 
SB0W6L2  AVDD      770       690 
         This is another AVDD2 problem. 
         It nev er initialized today. 
         Well the nominal make more sense than the reading. 
         (It is what the current should be if it was working)  
         Looking at IFIX plot for it has been "LOW" for a while 
         and I leave it as it is. 
SB2W4L2  AVDD     825 mA      740 mA 
SB2W4L4  AVDD     1115 mA     955 mA 
         These 2 are part of the wedge where we suspect a  
         problematic connection between the FIB and the CPC.  
         Beeing the nominal closer to the expected values and 
         being the unstable behavior during the day today I  
         leave them unchanged. 
SB5W3L4  DVDD     150 mA      275 mA 
         These one has no problem initializing at all. 
         Looking at IFIX plots the current jumps between these 2  
         states during the day 
         If we do not have any major problem with this device 
         I suggest to change the nominal to something 
         like 210 so that both value are inside the 70 mA band. 
          
SB5W8L4  DVDD     220 mA      150 mA          
         Well, I wanted to change the nominals but I just realized that with the procedure I know (stop-Options etc...) the wedge number goes only from 0 to 5 and not all the way up to 11 so I cannot do it. 
</pre>
<!-- Author: Gino -->


<!-- Date: Tue Jan 29 00:17:11 2002 -->
<pre>SB5W2L1-3-4 (all 3 layers that are enabled in this wedge) turned pink at 23:46:11 this is 30 seconds after an HALT from the DAQ side. This behavior is very similar to what was noticed in the past for SB0W2. 
 
</pre>
<!-- Author: Gino -->
<!-- Comment: Tue Jan 29 09;06;37 comment by...Lester -->
<pre>This is known behaviour for this wedge.</pre>


<!-- Date: Tue Jan 29 09:23:18 2002 -->
<pre>I chechked Run136997 using silicheck. 
 
Run136997 was taken 1/14 11:45 - 12:20 . 
 
 
In Run136997, based on data from stream B 
========================================== 
 
SB0W0L2 : There are few cluster on track on r-phi side. 
          all chips on z-side are dead.  
 
SB0W2L0 : Both sides are dead. 
 
SB0W2L1 : Both sides are dead. 
 
SB0W2L3 : Both sides are not Landau shape, spread broadly. 
          The number of cluster on track on z-side are very few. 
 
SB0W2L4 : Both sides are dead. 
 
SB0W3L2 : Both sides are dead.  
 
SB0W6L1 : Both sides are not Landau shape.  
          (Cluster on trk)/(All cluster) is low. 
          Already reported. 
 
SB1W0L4 : Landau peak of r-phi side 4th chip is around 20. 
 
SB1W1L0 : r-phi side is not Landau shape, spreaded broadly. 
          Already reported. 
 
SB1W2L2 : z-side is dead.  
 
SB1W4L0 : r-phi side 2nd chip is dead. z-side is dead. already reported. 
 
SB1W4L1 : Both sides are dead. Already reported. 
 
SB1W4L2 : Both side are dead. Already reported. 
 
SB1W4L4 : Both sides are dead. Already reported. 
 
SB1W11L0 : r-phi side is not Landau shape, spreaded broadly. 
 
SB2W5L0 : r-phi side is stuck bit. z side is dead. 
          I found stuck bit report for this ladder in silicon e-log. 
&lt;a href= '/cgi/elog/det-system-elog.pl?nb=silicon&action=copyentry&page=91&time=06:32:59'&gt; here&lt;/a&gt; 
 
SB2W7L4 : Both sides are not Landau.  
          This ladder was stuck bit in Run135614, but not now. 
          already reported. 
  
SB2W9L0 : r-phi side is not Landau shape, spreaded broadly.  
          z-side is good. Already reported. 
 
SB2W9L2 : r-phi 2nd chip is dead. z side 2nd chip is low occupancy. 
           
SB2W11L0 : r-phi is not Landau shape, spreaded broadly. 
           Already reported. 
 
SB3W0L2 : z side is low occupancy compared with r-phi side. Already reported. 
 
SB4W0L4 : Both sides are dead. 
 
SB4W5L0 : r-phi side is not Landau shape. broad. 
          Already reported. 
 
SB5W3L4 : r-phi 5t chip is dead and z side 5th chip is low occupancy. 
          SILIMONBROWSER r-phi last chip  
 
SB5W5L0 : r-phi side is not Landau, broad. 
 
SB5W9L0 : r-phi side is not Landau, broad. 
</pre>
<!-- Author: Naho -->
<!-- Comment: Tue Jan 29 15;28;00 comment by...Jason -->
<pre>I compared this list above to the list of known readout problems.
The "broad Landaus" are the obvious difference, ladders which 
read out fine but are flagged bad by SiliCheck.  They are:

SB1W1L0   SB1W11L0   SB2W9L0   SB2W9L2   SB2W11L0  
SB3W0L2   SB4W5L0    SB5W5L0   SB5W9L0

(Of course there are many readout problems not in the Naho's list.)</pre>
<!-- Date: Tue Jan 29 09:40:31 2002 -->
<pre>I came in to turn the Silicon from On to STDBY and due to a bad communication between our control room and the main control room (actually Bob says it was miscomunication inside the main control room) we suffered a few spikes of proton losses with the bias on. 
This lasted for a few minutes around 8:45 am. 
This should be rememberred if anything weird will be found off line. 
None of our ladders tripped 
. 
 
</pre>
<!-- Author: Gino -->



<!-- Date: Tue Jan 29 13:35:50 2002 -->
<h3>Attemting CalibSvx Mode</h3> 
Calib SVX mode is a Calibration mode of the TS where it sends 
4 L1A with arbitrary spacing between them, made especially  
for the Si to sample fixed BE states or buckets (similar 
to the 2 L1A scan).  Since they went to such effort, it would 
be a shame not to use it...one thing for sure is  
that one has to remove the "svx398Mode" flag from 
the calibration machine, else it vetoes anything not 
on a BXING (which are not spaced in 132 ns buckets).  Then 
one has to be careful to set the spacing, so I took a bunch of  
runs with different parameter settings to see if we could figure out what gives.  The runs are in fcdfsgi2:/cdf/data05/s1/hardware/svxii of the format  
<I>runNumber</I>.edm, roughly 40 events in each.  One hopes 
to see the same pattern of 4 Bunch Crossings repeated over and over (taken with the SEVB, via the Calibration Consumer which 
promises to send the file writer every event, so there should 
be no reordering.). 
Here's the parameter table: 
<table> 
      <tr> <th> Run </th> <th> CalibPipe </th> <th> Calib Int</th> <th> Int 0</th><th> Int 1</th><th> Int 2</th><th> Int 3</th> <th> Start on B0</th> </tr> 
      <tr> <td> 137753 </td> <td> 0 </td> <td> 0 </td> <td> 0 </td> <td> 0 </td> <td> 0 </td> <td> 0 </td> <td> true </td> </tr>   
      <tr> <td> 137756 </td> <td> 0 </td> <td> 0 </td> <td> 1 </td> <td> 2 </td> <td> 3 </td> <td> 4 </td> <td> true </td> </tr>   
      <tr> <td> 137759 </td> <td> 25 </td> <td> 0 </td> <td> 1 </td> <td> 2 </td> <td> 3 </td> <td> 4 </td> <td> true </td> </tr>   
      <tr> <td> 137771 </td> <td> 25 </td> <td> 10 </td> <td> 1 </td> <td> 2 </td> <td> 3 </td> <td> 4 </td> <td> true </td> </tr>   
      <tr> <td> 137772 </td> <td> 25</td> <td> 158 </td> <td> 1 </td> <td> 2 </td> <td> 3 </td> <td> 4 </td> <td> true </td> </tr>   
      <tr> <td> 137778 </td> <td> 25 </td> <td> 0 </td> <td> 0 </td> <td> 1 </td> <td> 2 </td> <td> 3 </td> <td> true </td> </tr>   
      <tr> <td> 137779 </td> <td> 22</td> <td> 0 </td> <td> 0 </td> <td> 1 </td> <td> 2 </td> <td> 3 </td> <td> true </td> </tr>   
      <tr> <td> 137780 </td> <td> 26 </td> <td> 0 </td> <td> 0 </td> <td> 0 </td> <td> 0 </td> <td> 0 </td> <td> true </td> </tr>   
      <tr> <td> 137787 </td> <td> 27 </td> <td> 10 </td> <td> 0 </td> <td> 0 </td> <td> 0 </td> <td> 0 </td> <td> true </td> </tr>   
      <tr> <td> 137789 </td> <td> 27 </td> <td> 0 </td> <td> 0 </td> <td> 0 </td> <td> 0 </td> <td> 0 </td> <td> true </td> </tr>   
      <tr> <td> 137790 </td> <td> 30 </td> <td> 0 </td> <td> 0 </td> <td> 0 </td> <td> 0 </td> <td> 0 </td> <td> true </td> </tr>   
      <tr> <td> 137791 </td> <td> 30 </td> <td> 20 </td> <td> 0 </td> <td> 0 </td> <td> 0 </td> <td> 0 </td> <td> true </td> </tr>   
      <tr> <td> 137792 </td> <td> 0 </td> <td> 25 </td> <td> 4 </td> <td> 6 </td> <td> 8 </td> <td> 10 </td> <td> true </td> </tr>   
</table> 
 
One should be able to use this to figure out how to set the sampling.  My understanding is something like<ul> 
<li> CalibPipe = # of ticks (132 ns) between Cal Engine start 
and Cal Enable Signal 
<li> Calib Int(erval) = # of ticks between successive sets of 4 Events 
<li> Int(erval) 0  = # of ticks between Cal Enable Signal and 
first L1A 
<li> Int(erval) 1  = # of ticks between first and second L1A 
<li> Int(erval) 2  = # of ticks between second and third L1A 
<li> Int(erval) 3  = # of ticks between third and fourth L1A 
<li> Start on B0 = forces the sets of events to be synched with B0 
</ul> 
However, I am not sure the above is correct-it was suggested 
that I should just try and see what gives. With that in mind, 
I did, and found that I could move the first Event's BXing around 
and in some files I did see a subset of 4 BXing numbers, but 
not in the correct order.  Of course, my analysis tool 
was simply hex dumping, so I thought maybe I am confusing  
myself, and need a more sophisticated analysis tool.  I am hoping 
to get a version of svxMon that stripcharts the BXING...
<!-- Author: SCN -->
<!-- Comment: Tue Jan 29 17;22;49 comment by...SCN -->
Turns out my interpretation was a little wrong, but
I got Henri to make svxmon do what I want.  The plots
for BXING vs. Event number are called BX<runumber>.ps
and can be seen <a href='/svx-data1/workarea/'>here</a>.
Looks like it works if we go on the assumption that I did
not actually catch every event, which is co-oberated by the
fact the svxmon reports errors on for instance event 61 when
I only told it to process 40 events.  I'll run that by the CSL
people to see if they guarentee every event using the SEVB and
the calibration CSL plus their "test" code based on 4.1.0 (there
are differences with that and the development version). 
<!-- Date: Tue Jan 29 15:22:08 2002 -->
<h2><font color=blue>Changed AVDD2 ISEL bits to 0 
</h2></font> 
<pre> 
The following chips have ISEL=0 and threshold 255 
SB0W0L2 87	(previously changed) 
SB0W1L2 A4 
SB0W6L2 A1 
SB3W3L4 8A 
SB4W3L2 A4 
</pre>
<!-- Author: Lester -->



<!-- Date: Tue Jan 29 16:53:58 2002 -->
<pre>For recent calibration runs - state of the magnet 
 
 Run #        Date & time       Events    DPS   Run type  Field 
------    -------------------   ------    ---   --------  ------- 
137337    01/17/2002 01:56:03     5105     on    D_PED    ON 
137338    01/17/2002 02:06:33     5123    off    D_PED    ON 
 
137357    01/17/2002 12:13:49     3031    off    D_PED    OFF 
137361    01/17/2002 12:27:40     3600     on    D_PED    OFF 
137375    01/17/2002 13:39:16     3859    off    D_PED    OFF 
 
137417    01/18/2002 04:34:05     5132     on    D_PED    ON 
137418    01/18/2002 04:41:58     5098    off    D_PED    ON 
 
137427    01/18/2002 12:34:40     3164     on    D_PED    OFF 
 
137447    01/18/2002 13:55:06     5180     on    D_PED    OFF 
137448    01/18/2002 14:04:25     5074    off    D_PED    OFF 
 
137471    01/18/2002 21:35:17     5096     on    D_PED    ON 
137472    01/18/2002 21:43:10     5091    off    D_PED    ON 
 
137479    01/19/2002 04:10:18     5070     on    D_PED    ON 
137482    01/19/2002 04:32:08     5073    off    D_PED    ON 
 
137489    01/19/2002 12:34:22     2677     on    D_PED    OFF 
137491    01/19/2002 12:39:20     2566    off    D_PED    OFF 
 
137622    01/21/2002 13:47:11     5150     on    D_PED    OFF 
137627    01/21/2002 14:25:29     5187    off    D_PED    OFF 
137630    01/21/2002 14:32:33     5077     on    D_PED    OFF 
 
137668    01/22/2002 00:40:21     5087     on    D_PED    OFF 
137670    01/22/2002 00:48:02     5106    off    D_PED    OFF 
 
137884    01/24/2002 18:29:35     5144     on    D_PED    OFF 
137885    01/24/2002 18:39:19     5050     on    D_PED    OFF 
137894    01/24/2002 19:51:42     5131     on    D_PED    OFF 
137895    01/24/2002 20:02:42     5055    off    D_PED    OFF 
 
137947    01/25/2002 15:13:26     5103    off    D_PED    OFF 
137949    01/25/2002 15:21:48     5123     on    D_PED    OFF 
 
138042    01/27/2002 11:16:52     5081     on    D_PED    ON 
138043    01/27/2002 11:25:05     5070    off    D_PED    ON 
 
138059    01/28/2002 09:13:20     5059     on    D_PED   OFF 
138060    01/28/2002 09:20:45     5079    off    D_PED   OFF 
 
138094    01/28/2002 20:32:05     5065     on    D_PED   OFF 
138095    01/28/2002 20:39:24     5111    off    D_PED   OFF 
</pre>
<!-- Author: Jean -->



<!-- Date: Tue Jan 29 19:06:34 2002 -->
<pre>Ricardo just fixed a small bug in IMON. 
Here are the details: 
 
 
   Yes, you are right. 
   I'll fix taht today. 
 
   Thanks, 
 
 
   Bolla Gino wrote: 
 
   &gt; Ricardo I believe there is a small bug in IMON. 
   &gt;  
   &gt; On the IMON Options window the pull down menu associated with the:  
   &gt; barrel gives you choices from 0 to 11 
   &gt; wedge gives you choices from 0 to 5  
   &gt;  
   &gt; With what I did last night I'm pretty sure that the labels are correct: 
   &gt; BARREL really means barrel 
   &gt; and 
   &gt; WEDGE really means wedge 
   &gt;  
   &gt; SO we are now in a situation where we cannot change the nominals through 
   &gt; this window for half of the SVXII. 
   &gt; Everything is actually OK for ISL and L00 because they go from 0 to 5. 
   &gt;  
   &gt;  
   &gt; Could you verify what I said and, assuming I'm right,  change it according 
   &gt; to the real geometry 
   &gt;  
   &gt; thank you 
   &gt;  
   &gt; Gino 
   &gt;  
 
</pre>
<!-- Author: gino -->