<!-- Title: 19:27:23  Sat Mar  9 2002 -->
<!-- Crewchief: SiliPeople -->
<!-- Op1: &nbsp; -->
<!-- Op2: &nbsp; -->
<!-- Op3: &nbsp; -->
<!-- Op4: &nbsp; -->
<!-- Op5: &nbsp; -->
<!-- Op6: &nbsp; -->
<!-- Notes: -->
<pre>Running Silicon - new store about to come.</pre>


<!-- Date: Sun Mar 10 03:38:46 2002 -->
<pre>Paged for two reasons: 
1) IB5W1L2 does not init. 
   RC tried 3 times 02:37:00 02:39:01 02:42:25 
   each time reads out ff 
   -&gt; exclude from configuration. 
   Currents look reasonable. 
2) rebooting b0fib07 crate gives errors for slot 12 ch 5-9 
   this wedge is IB3W3 and is off-line. 
    I'd tend to ignore this by now and report problem to DAQ 
</pre>
<!-- Author: Saverio -->
<!-- Comment: Mon Mar 11 09;24;25 comment by...SCN -->
The "errors" for IB3W3 are simply because there is no
IB3W3 (ISL Central has 3 PCs i.e. 3 "wedges" 0,1,2) but the database thinks there is.  They are harmless, but we'll try
to get rid of them anyway.  Similar statements apply for
any HDI 4 (ch 4 or 9) on any L00 Fib, and for the SOC/pitwib
wedge.
<!-- Comment: Thu Mar 21 18;14;15 comment by...Gino -->
<pre>Looks like we made a decision that is questionable here.
We excluded a ladder (SB5W1L2 ONLINE FLAG FROM 1 to 0) just because it was failing Initialization.
Usually we try to mask the INIT first and then if necessary we get the ONLINE FLAG changed to 0. 

This ladder failed INIT once on 03-09-2002 spiting out a NON consistent number of ffs
5 more times the day after spiting out ffs all the times.
maybe it was the right choice.

</pre>
<!-- Date: Sun Mar 10 06:40:14 2002 -->
<pre>Called around 5:00 am because they had to DISABLE the trigger INhibit. 
I came in a little later and it took me a while to find out that: 
SB2W10 was in STDBY instead of ON. 
This wedge was reintegrated yesterday after being out for a day. 
I had run # 140721 stopped. 
I changed the status of SB2W10 from STDBY to ON. 
I ENABLED the TRIGGER INHIBIT 
We had run # 140722 started without any problem and still taking data. 
We lost a total of 5 minutes of data taking between the 2 runs. 
 
 
</pre>
<!-- Author: Gino -->
<!-- Comment: Sun Mar 10 22;34;27 comment by...Saverio -->
<pre>The reason for this can be traced back to powerset.dat not being
loaded when this wedge was reintegrated. Sorry about that.
It would be nice to now have a more automated mechanism to load the constants.</pre>
<!-- Date: Sun Mar 10 09:37:22 2002 -->
<pre>I have added a message to ./cratematch to esplicitly warn about 
a possible TRIGGER INHIBIT from Silicon on "Activate". </pre>
<!-- Author: Saverio -->


<!-- Date: Sun Mar 10 12:37:50 2002 -->
<pre>The DAQ ACE just mentioned to me a NON negligible rate of reformatter errors. 
From the reformatter itself the device source of most of them is : 
SCPU 	13 
VRB 	0 
LINK 	6 
 
This is equivalent to SB5W1L1 
This ladder is RED in SVXMON and seems to be able to readout very little and with CAPIDs always out of sync. 
From the e-log I have other devices in the same wedge with this problem. Still nothing correlated specifically with this layer. 
 
If the main silicon pager gets paged because of reformatter errors we should try to COLDSTART first and if problem persist take this specific ladder out and see the how it develops.</pre>
<!-- Author: Gino -->
<!-- Comment: Sun Mar 10 16;46;42 comment by...Saverio -->
<pre>In addition to this, it would be nice to know which run the ace
 was seeing reformatter errors and what the exact rate was. 
I am digging in the errorlogfiles.</pre>


<!-- Comment: Mon Mar 11 07;32;23 comment by...SCN -->
Please be very careful in trusting the "SCPU/VRB/LINK" numbers.
They are not correct a non-negligible percent of the time.
You should look into the details of the error reported to
id the troubled ladder accurately.  For details, see
the <a href=
'/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=93&frame=2&anchor=16:36:26'>dissertation on Reformatter Errors</a>.

<!-- Date: Sun Mar 10 16:51:57 2002 -->
<pre>Run140728 - SB2W11L4 did not init correctly the first time. 
Manual transition abort-&gt;Config on b0fib00 (i.e. re-init only 
ladders in that crate) solved the problem.</pre>
<!-- Author: Saverio -->

<!-- Date: Sun Mar 10 16:59:01 2002 -->
<p><font size=+1> D-mode Calibration Job Started </font>
<p><pre>
Job id            : 99
Calibration type  : standard
Run period tag    : Mar_2002
DPS-off run       : 140728
DPS-on run        : 140727
Requested by      : Henri
Main process id   : 12001786
</pre>
<!-- Author: CDF silicon D-mode calibration job server v1.3 -->


<!-- Date: Sun Mar 10 22:01:10 2002 -->
<p><font size=+1> D-mode Calibration Job Finished </font>
<p><pre>
This is a computer-generated silicon D-mode calibration status report.
Silicon D-mode calibration job 99 finished successfully.

Job info
--------
Calibration type : standard
DPS-off run      : 140728
DPS-on run       : 140727
Requested by     : Henri
Submitted        : 2002-03-10 14:58:59
Completed        : 2002-03-10 20:00:36
Status           : SUCCESS
</pre>
<!-- Author: D-mode script run_calib_analysis.tcl -->




<!-- Date: Mon Mar 11 01:02:58 2002 -->
<pre>Silicon successfully turned ON. Losses at 18k (lostp) and 6k 
(lostpb). All Si came up at once, no need of intervention. 
(let's also write the good things!)</pre>
<!-- Author: Saverio -->




<!-- Date: Mon Mar 11 12:53:48 2002 -->
<h3>Sequence Check</h3> 
Current sequence checksum is (<a href= 
'/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=101&frame=2&anchor=10:24:40'>still</a>) 0x19c82.  Checked all but b0fib01, currently needed for Access 
job.  Found 2 problems in these 53 fibs<ul> 
<li> b0fib02 Slot 10 SB0W8/9 Checksummed to 0x19c83 (1 bit difference) 
<li> b0fib00 Slot 15 SB1WA/B Checksummed to 0x19c92 (16 bit difference) 
</ul> 
 These have not had Sequence problems before, to my knowledge. 
To retore them, this time I just restored the sequence from 
the EE prom (rather than from the file) and then they were ok (I rechecked all afterwards).  Perhaps the PROM is not as volatile 
as the memory.  We could imagine some sort of check and 
pull from PROM mechanism if necessary.  
<!-- Author: SCN -->


<!-- Date: Mon Mar 11 14:02:29 2002 -->
<pre>Controlled Access: 
 
LB0W3 PS with 5V DOIM OV investigated. 
Problem found to be with PS, PS removed. 
Spare L00 PS installed and LIB tested, and connected. 
Crowbar replaced, blown fuse on ch 0. 
 
LB0W3 re-integrated. 
 
Now draws 0.18 uA at 80V on ch0 bias, so maybe crowbar was reason 
no physics seen on LB0W3L0.  Check next run.</pre>
<!-- Author: Chris Hill -->
<!-- Comment: Mon Mar 11 15;50;56 comment by...Saverio -->
<a href=
'/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=101&frame=2&anchor=09:38:23'>
My previous suspicion </a> on this PS was right. 
<!-- Comment: Thu Mar 14 13;45;22 comment by...Napora -->
<b>A comment on the blown crowbar channel</b>
<p>According to Dave's PS webpage the current draw on LB0W3 Bias0 dropped to
0 uA at 0628 on 3/7/2002.  At this time there was NO BEAM in the
machine--it's not clear exactly when the beam went off, but it was before
0617 that morning--so it does not look like we tripped from radiation
activating the SCR.  The wedge was going from STDBY->ON at the time,
however.<p>

<!-- Date: Mon Mar 11 14:52:12 2002 -->
I caught Jonathan Lewis and made him figure out why the ISL 
trigger inhibit wasn't working.  He found out he needs to 
replace a piece of hardware and in the meantime he kludged it 
such that it works, 
<a href= 
'/cgi/elog/elog.pl?nb=2002&action=view&page=209&frame=2&anchor=12:49:08'> 
but it is un-ignoreable.</a>  I will keep on him to fix it for 
real.  
<!-- Author: Andy H. -->



<!-- Date: Mon Mar 11 16:22:12 2002 -->
<table><tr><td><a href=/elog/notebooks/silicon/Mon_Mar_11_2002_162201.ps align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-403  align='top'></td><td>On Gino's phone call: IMON event that happened at 12:39:56 ISL and L00 have the same "purple plague" (not due to Au-Al this one!)</a></td></tr></table>
<!-- Author: Saverio -->
<!-- Comment: Mon Mar 11 16;48;43 comment by...SCN -->
Probably when I was checking the sequences.
<!-- Comment: Mon Mar 11 17;09;57 comment by...Gino -->
<pre>17:00 I cleared all pinkies after making sure with S. Nahn that
they were generated when checking the FIB sequences.
Furthermore I changed the nominals for SB3W6 and SB3W7 to the values as read right now.
I really believe I got them wrong when I set them in the past.

</pre>
<!-- Date: Mon Mar 11 16:22:26 2002 -->
<h1>iFix logging of PS data has been disabled</h1> 
The large data volume crashed the iFix historian several 
times over the weekend, prompting Bill Noe to disable it. 
IMON and the Auke-Pieter plots are still available for 
viewing current histories.
<!-- Author: Andy H. -->




<!-- Date: Mon Mar 11 17:12:11 2002 -->
<pre>Silicon in STDBY. 
Running cratematch.pl I find that: 
 
The following wedges are in high stand-by mode:  
IB5W5L31   
 
This ladder is actually in STDBY, its VSET is 2 V but VMON is 2.8-2.9 V. I bet this is the reason for it. 
 
</pre>
<!-- Author: Gino -->


<!-- Date: Mon Mar 11 17:37:20 2002 -->
<pre>The following L00 hdis should be considered under study and  
ignored for physics: 
 
They have diagnostic chip settings which will make their data 
useless, except to me. 
 
f821 
f823 
f831 
f850 
fa00 
fa01 
fa21 
fa22 
fa51 
 </pre>
<!-- Author: Chris Hill -->

<!-- Date: Mon Mar 11 22:05:27 2002 -->
<p><font size=+1> D-mode Calibration Job Started </font>
<p><pre>
Job id            : 100
Calibration type  : standard
Run period tag    : Mar_2002
DPS-off run       : 140798
DPS-on run        : 140796
Requested by      : slava/DAQ
Main process id   : 22450522
</pre>
<!-- Author: CDF silicon D-mode calibration job server v1.3 -->


<!-- Date: Mon Mar 11 22:06:25 2002 -->
<p><font size=+1> D-mode Calibration Job Finished </font>
<p><pre>
This is a computer-generated silicon D-mode calibration status report.
Silicon D-mode calibration job 100 FAILED.

Job info
--------
Calibration type : standard
DPS-off run      : 140798
DPS-on run       : 140796
Requested by     : slava/DAQ
Submitted        : 2002-03-11 20:05:24
Completed        : 2002-03-11 20:06:16
Status           : FAILURE

Last processing stage reported : checking silicon configuration
Failure diagnostics :
error {child process exited abnormally}
Exiting.
</pre>
<!-- Author: D-mode script run_calib_analysis.tcl -->



<!-- Date: Tue Mar 12 12:00:55 2002 -->
<pre>L00 commissioning - made temporary global change to BW=5, except 
problem wedges listed below which temporarily have BW=7.   
 
f821  
f823  
f831  
f850  
fa00  
fa01  
fa21  
fa22  
fa51 
 </pre>
<!-- Author: Chris Hill -->
<!-- Comment: Tue Mar 12 14;30;32 comment by...CH -->
<pre>Changes take effect with run 140808.</pre>
<!-- Date: Tue Mar 12 13:06:19 2002 -->
<pre>taken the silicon from Shift CREW around 9:00 am 
by coldstart e571 failed INIT a few times. Look at: 
/svx-data1/datalog/daq/20020312.si_daq 
searching for e571. 
We MASKED the readback of the bitstream on the HDWDB for this device. 
 
We started working on SB4W4. 
We runned with it for 3 hours with only one problem: 
the full wedge went in a HIGH DVDD current state during a  
PAUSE-RESUME transition in RC. 
This was not repeatable so we cannot carry out conclusions. 
We left this wedge integrated in the HDWDB in order to  
accumulate more statistic. 
Silicon given back to CDF CREW at 1:00 pm but they are having trouble with L2. 
</pre>
<!-- Author: Gino -->
<!-- Comment: Tue Mar 12 13;07;01 comment by...GINO -->
<pre>ACTUALLY SCN (Steve Nahn) was working with me in all this.</pre>



<!-- Date: Tue Mar 12 18:56:41 2002 -->
<pre>Due to problems with b0dap30 we have been without "spy programs" 
for about 36 min. (affects IMON, possibly calibration). 
New time 63946 Tue Mar 12 17:45:46 2002 
New time 66061 Tue Mar 12 18:21:01 2002 
Programs restarted.</pre>
<!-- Author: Saverio -->


<!-- Date: Tue Mar 12 20:52:12 2002 -->
Paged for Reformatter Errors > 5%.  Cold Start fixed it.  Diagnosis of error file <a href= 
'/cgi/elog/elog.pl?nb=2002&action=view&page=213&frame=2&anchor=19:57:01'>here</a>.   
<!-- Author: SCN -->


<!-- Date: Tue Mar 12 23:34:53 2002 -->
Came back to replace VRBs for wedges taken out<a href= 
'/cgi/elog/elog.pl?nb=2002&action=view&page=212&frame=2&anchor=16:06:33'> 
before.</a>   Symptom was !DONE (i.e. the VRB getting  
READ BUSY for VRBS for wedges SB0W8/W9 and IB1W4/W5) which would 
then hang the SRC, allowing no processing of further L1A or L2A-this 
would cause all of SVT to not get the next L1A data from the Silicon, which causes a L2 Timeout with a Synch Error. 
Replaced the Vrbs 
<table> 
<tr> <th> In/Out <th> node <th> slot <th> wedges <th> S/N <th> PREP </tr> 
<tr> <td> OUT  <td> b0svx00 <td> 18 <td> SB0W8/W9 <td> 459 <td> 564215 </tr>  
<tr> <td> IN  <td> b0svx00 <td> 18 <td> SB0W8/W9 <td> 145 <td> 551019 </tr>  
<tr> <td> OUT  <td> b0svx08 <td> 11 <td> IB1W4/W5 <td> 184 <td> 564210 </tr>  
<tr> <td> IN  <td> b0svx08 <td> 11 <td> IB1W4/W5 <td> 107 <td> 550280 </tr> 
</table>  
3.3 million L1A without any problems like before, so I'd say this 
was a successful operation.
<!-- Author: SCN -->

<!-- Date: Wed Mar 13 01:32:51 2002 -->
<p><font size=+1> D-mode Calibration Job Started </font>
<p><pre>
Job id            : 101
Calibration type  : standard
Run period tag    : Mar_2002
DPS-off run       : 140835
DPS-on run        : 140834
Requested by      : Diego Tonelli
Main process id   : 26587834
</pre>
<!-- Author: CDF silicon D-mode calibration job server v1.3 -->



<!-- Date: Wed Mar 13 08:53:13 2002 -->
There were a truckload of reformatter errors in the early 
stages of run 140851 (owl shift).  Unfortunately all I can 
say is that they occurred somewhere between 6:30 and 8:00.... 
See <a href= 
'/cgi/elog/elog.pl?nb=2002&action=view&page=215&frame=2&anchor=08:13:48'> 
CDF e-log</a>   
<!-- Author: Andy H. -->


<!-- Date: Wed Mar 13 09:14:36 2002 -->
<pre>Gui spy was not running last night for about 28 min. 
New time 17633 Wed Mar 13 04:53:53 2002 
New time 19267 Wed Mar 13 05:21:07 2002 
It was restarted by the cron-job or by Steve Nahn at 05:21:02 
</pre>
<!-- Author: Saverio -->

<!-- Date: Wed Mar 13 12:32:40 2002 -->
<p><font size=+1> D-mode Calibration Job Finished </font>
<p><pre>
This is a computer-generated silicon D-mode calibration status report.
Silicon D-mode calibration job 101 FAILED.

Job info
--------
Calibration type : standard
DPS-off run      : 140835
DPS-on run       : 140834
Requested by     : Diego Tonelli
Submitted        : 2002-03-12 23:32:17
Completed        : 2002-03-13 10:32:19
Status           : FAILURE

Last processing stage reported : calculating DPS-on pedestals
Failure diagnostics :
child killed: segmentation violation
</pre>
<!-- Author: D-mode script  -->



<!-- Date: Wed Mar 13 13:58:02 2002 -->
<pre>L00 now globally BW = 5 (as of run 140853).</pre>
<!-- Author: Chris Hill -->
<!-- Comment: Wed Mar 13 16;53;42 comment by...CH -->
<pre>L00 problem wedges back to BW =7, and bias ratio = 0 as of 140863</pre>
<!-- Date: Wed Mar 13 13:59:03 2002 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-404&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-405  width='300' align='top'></td><td>Something new for a change. IB3W0L4 is a power supply that is meant to be connected  to a UNCOOLED ISL wedge and so it is OFF all the time. (The cables are not really connected to the PS.) Today we had an alarm from the GUI saying that: IB3W0L4 is reporting voltages higher than 2 V when it is OFF. Well the plot here shows the behavior of that voltage vs time. The reason to report it here is that one day we will have to  connect those cables and maybe better to get this PS out  before that day come.</a></td></tr></table>
<!-- Author: Gino -->

<!-- Date: Wed Mar 13 15:33:19 2002 -->
<p><font size=+1> D-mode Calibration Job Started </font>
<p><pre>
Job id            : 102
Calibration type  : standard
Run period tag    : Mar_2002
DPS-off run       : 140856
DPS-on run        : 140855
Requested by      : I.P. Freely
Main process id   : 28206794
</pre>
<!-- Author: CDF silicon D-mode calibration job server v1.3 -->


<!-- Date: Wed Mar 13 15:33:19 2002 -->
<p><font size=+1> D-mode Calibration Job Started </font>
<p><pre>
Job id            : 102
Calibration type  : standard
Run period tag    : Mar_2002
DPS-off run       : 140856
DPS-on run        : 140855
Requested by      : I.P. Freely
Main process id   : 28206794
</pre>
<!-- Author: CDF silicon D-mode calibration job server v1.3 -->




<!-- Date: Wed Mar 13 19:10:31 2002 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-406&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=-406  width='300' align='top'></td><td>Losses for everybody excitement! </a></td></tr></table>
<!-- Author: Mircea C -->
<!-- Comment: Wed Mar 13 19;11;04 comment by...Mircea C -->
<pre>Silicon turned ON!</pre>


<!-- Date: Wed Mar 13 19:35:37 2002 -->
Bias does not come up for L00 East W4 and W5.  Mircea 
and I tried to redownload CAENVolts.dat, but still 
the VOSet is 0.  We also try setting the Bias by hand, and 
the GUI accepts the values and updates V0Set, but only 
for a little while (probably 1 refresh time) after which 
the Set values return to zero.<p> 
Mircea is paging Andrew to make sure there is nothing 
he and Doug did which might cause this, I am paging Chris 
to see if this is potentially an affect of the crowbar or 
something.  They <a href= 
'/cgi/elog/elog.pl?nb=2002&action=view&page=216&frame=2&anchor=19:05:18'>lost a COT VME PS</a> which indicates potentially damaging losses.<p> 
I told them also to continue to run as two wedges of L00 is not 
at this point critical enough to stop all data taking until the 
problem is fixed (it is not clear anyone can make physics use of the L00 data even when it is biased...)
<!-- Author: SCN -->


<!-- Date: Wed Mar 13 21:27:30 2002 -->
<pre>Please pay special attention to the following L00 wedges 
East #4 and L00 East  #5. We had trouble applying bias 
voltage to them earlier this evening. They are now working?!?!? 
If they trip off again, please keep them off until the  
access. Page the general pager so that hardware database 
can be changed. 
 
I could not set the voltages by hand initially. They kept setting 
their voltages back to 0 V. 
When I sent the ladders to standby they responded correctly  
until the next update cycle when they would turn themselves on 
with 0 volts. They could have their bias voltages set to  
anything other than 0 volts. (The standby bias setting is 2V). 
 
To make sure that the problem was not the gui, I reverted to an 
old version. I then was able to set L00 East wedge #4 to standby. 
 
I then reinstalled the latest version of the gui and server code 
and was able to set L00  East wedge #5 to standby. 
 
Using the lastest version of the code I was able to turn on both 
wedges and they still have bias voltage as I write this message. 
 
I think that these supplies should be looked at during the next 
access.</pre>
<!-- Author: Doug B -->


<!-- Date: Wed Mar 13 21:55:46 2002 -->
<pre>Working with Doug Benjamin. 
Reacting to the following accident: 
LB1W3L3 tripped on UNDER Voltage on the bias line 0 (not 1) 
turned back to STDBY OK 
Tried to bring it to 125 VOLTS (still bials line 0) but it tripped on EXTERNAL TRIP. 
So we decided to remove the ladder from the HDWDB. 
Created a new CAENvolts_HDWDB.dat 
Compared it with the previous file and copied it over to the  
right directory. 
Downloaded it to the GUI. 
 
According to Chris this is (UNDERVOTAGE TRIP) the behavior expected when the SCR in the crowbar activates. 
 
</pre>
<!-- Author: Gino -->


<!-- Date: Thu Mar 14 03:02:47 2002 -->
<pre>Well here is a nice story: 
I spent some time tonight with Bill loking at some readout times  
and other connections between SVT and Silicon. 
Well during this time we (actually Bill) did a lot of crazy stuff because ONE COT crate is dead and the data is going to the garbage can anyway. So we changed all the trigger tables we went up to a 10KHz L1A rate (The silicon did NOT start to smoke). 
During all this time (about 3 hours) the reformatter error rate was around 3% but nobody cared because the data is garbage anyway. 
We were a little tired and we decided to go home. 
Well thanks to a very professional DAQ ACE as soon as I got in my bed I got paged because the reformatter error rate was bigger than 1%. 
First thing first: The DAQ ACE is not so professional (she should have paged Steve). 
Anyway I got in and localized the trouble maker to be e511 (SB5W1L1) with some tricks that mircea showed to me today. 
I deintegrate it from the HDWDB with associated CAENvolts.dat upgrade copy and download. 
Now the reformatter error rate is less than 1%. 
 
A little by mistake and a little because the time allows to try things I waited to tunr OFF the ladder untill the Run was started. SO I basically turned OFF SB5W1L1 while RunControl was active with a configuration that did NOT included SB5W1L1.  
Well the trigger INHIBIT went OFF. 
 
I did NOT expect this but it actually happened. 
 
There are two possible explanation I see (and more I do not see): 
 
1- RC reads the HDWDB at PARTITION and NOT at COLD-START 
   (it was my understanding this is NOT the case) 
 
2- The trigger INHIBIT logic is a little different from my logic. 
 
</pre>
<!-- Author: Gino -->
<!-- Comment: Thu Mar 14 03;16;45 comment by...Gino -->
<pre>This developed into something worse:
I cannot find a way to reset the trigger INHIBIT.
NOBODY in the CDF shift Crew can do it either.
I decided to actually IGNORE the trigger INHIBIT just because of the special conditions (CDF is taking data just for the fun of it).
Cratematch.pl does NOT COMPLAIN about it.
It sounds to me like there is a little BUG on the logic but I leave the ball to Saverio and Andy Hocker to figure out what is happening.</pre>

<!-- Comment: Thu Mar 14 03;41;09 comment by...Gino -->
<pre>I'm comenting myself too many times. It is probably time to go to sleep.
Anyway I believe I found the reason of the trigger INHIBIT giving me trouble.
Basically to link the CAENvolts_&lt;date&gt;.dat to CAENvolts.dat I followed Saverio's suggestions:
ln -s  CAENvolts_&lt;date&gt;.dat CAENvolts.dat
but without removing the link before doing it so basically CAENvolts.dat did NOT get updated before reloading it.
I should have known better!

Still There is no reason to issue TRIGGER INHIBIT when all the ladders included in the HDWDB are actually powered and with the proper BIAS voltage to them so maybe the issue is still worth wome thoughts.
</pre>
<!-- Comment: Thu Mar 14 08;26;33 comment by...SCN -->
Try: ln -s<b>f</b>  CAENvolts_XXX.dat CAENvolts.dat
<!-- Comment: Thu Mar 14 10;22;25 comment by...Andy H. -->
This is exactly why the GUI ought to read the HDWDB directly
instead of using CAENvolts.dat as a middleman.
<!-- Date: Thu Mar 14 03:34:46 2002 -->
<p><font size=+1> D-mode Calibration Job Finished </font>
<p><pre>
This is a computer-generated silicon D-mode calibration status report.
Silicon D-mode calibration job 102 finished successfully.

Job info
--------
Calibration type : standard
DPS-off run      : 140856
DPS-on run       : 140855
Requested by     : I.P. Freely
Submitted        : 2002-03-13 13:33:14
Completed        : 2002-03-14 01:34:09
Status           : SUCCESS
</pre>
<!-- Author: D-mode script run_calib_analysis.tcl -->


<!-- Date: Thu Mar 14 03:34:46 2002 -->
<p><font size=+1> D-mode Calibration Job Finished </font>
<p><pre>
This is a computer-generated silicon D-mode calibration status report.
Silicon D-mode calibration job 102 finished successfully.

Job info
--------
Calibration type : standard
DPS-off run      : 140856
DPS-on run       : 140855
Requested by     : I.P. Freely
Submitted        : 2002-03-13 13:33:14
Completed        : 2002-03-14 01:34:09
Status           : SUCCESS
</pre>
<!-- Author: D-mode script run_calib_analysis.tcl -->





<!-- Date: Thu Mar 14 09:45:41 2002 -->
<pre>LB0W1 had 1mA Imax on DVDD bug re-appear, Doug/Andrew notified. 
All layers except LB0W1L3 were eventually turn-on-able, 
LB0W1L3 de-integrated temporarily, pending the bug fix.</pre>
<!-- Author: Chris Hill -->
<!-- Comment: Thu Mar 14 11;33;38 comment by...CH -->
<pre>LB0W1L3 re-integrated</pre>
<!-- Date: Thu Mar 14 11:32:04 2002 -->
<p><b>Controlled Access</b> 
<p>We swapped out the crowbar on <b>LB1W3</b>.  While doing this we noticed that both the remote sense (between the adapter and the cable) and bias (between the crowbar and cable) connections were a little askew.  Later diagnosis of the removed crowbar showed that it is still good. 
<p>We also double-checked the cabling of <b>LB1W4</b> and <b>LB1W5</b>.  LB1W5's bias connection (between the crowbar and cable) was slightly askew.  LB1W4 looked fine. 
<p>On all three of these supplies we noticed that the strain relief screws on the short bias adapter cable had been removed.  I am not sure who did this or why, but <font color="red">these screws do serve a mechanical purpose</font>, they are <b>not</b> intended to screw into another cable.  If you catch (or are) the gremlin who is doing this stop it.  We corrected the problem on LB1W3 since we had diconnected the cables anyways, but LB1W4 and LB1W5 still need this fix.
<!-- Author: Napora and Herndon -->
<!-- Comment: Thu Mar 14 11;38;48 comment by...CH -->
<pre>LB1W3L3 no longer has HV problems.  May have been due to ACE 
error (not clearing ext trips).  The UV trip could still 
have been caused by the crowbar if there was a voltage spike 
greater than 140V - and left the fuse intact.
In fact, this is what was seen during crowbar testing.
This should be re-coverable by re-settiing trips and re-powering,
which also seems to be the case in this incident.  But it was
good to go down and check things out.  </pre>


<!-- Date: Thu Mar 14 11:40:18 2002 -->
<pre>LB0W1L1 had been de-integrated for some time due to OC on DVDD. 
I have re-integrated it to aid L00 commissioning. If it causes 
problems again, it may need to be taken out.</pre>
<!-- Author: Chris Hill -->
<!-- Comment: Thu Mar 14 12;03;45 comment by...CH -->
<pre>Not only is this one causing problems, but now so is LB0W1L3.
Both de-integrated due to DVDD OC trips.</pre>

<!-- Date: Thu Mar 14 12:14:09 2002 -->
<p><font size=+1> D-mode Calibration Job Started </font>
<p><pre>
Job id            : 103
Calibration type  : standard
Run period tag    : Mar_2002
DPS-off run       : 140900
DPS-on run        : 140899
Requested by      : Y Shon
Main process id   : 521228
</pre>
<!-- Author: CDF silicon D-mode calibration job server v1.3 -->


<!-- Date: Thu Mar 14 12:16:26 2002 -->
<p><font size=+1> D-mode Calibration Job Finished </font>
<p><pre>
This is a computer-generated silicon D-mode calibration status report.
Silicon D-mode calibration job 103 FAILED.

Job info
--------
Calibration type : standard
DPS-off run      : 140900
DPS-on run       : 140899
Requested by     : Y Shon
Submitted        : 2002-03-14 10:12:49
Completed        : 2002-03-14 10:15:14
Status           : FAILURE

Last processing stage reported : checking silicon configuration
Failure diagnostics :
error {{ opening /data2/dauria/svx/cgi_data/temp_.dat} {Content-type: text/html} {} {&lt;H1&gt;Software error:&lt;/H1&gt;} {&lt;CODE&gt;can not open $tempfile file at /data2/dauria/svx/bias_run_txt_cgi.pl line 606.} &lt;/CODE&gt; &lt;P&gt; {For help, please send mail to the webmaster (&lt;a href="mailto:root@localhost"&gt;root@localhost&lt;/a&gt;), giving this error message } {and the time and date of the error.} {}}
Exiting.
</pre>
<!-- Author: D-mode script run_calib_analysis.tcl -->



<!-- Date: Thu Mar 14 16:48:03 2002 -->
<p><font size=+1> D-mode Calibration Job Started </font>
<p><pre>
Job id            : 104
Calibration type  : standard
Run period tag    : Mar_2002
DPS-off run       : 140900
DPS-on run        : 140899
Requested by      : Igor
Main process id   : 1707007
</pre>
<!-- Author: CDF silicon D-mode calibration job server v1.3 -->



<!-- Date: Thu Mar 14 17:33:48 2002 -->
<pre>Andrew and I found a bug that may have caused the unstable 
behaviour of the power supply server code that runs in 
the vme crate. There is no array bounds checking and we 
would write past the end an array when the crate number=16. 
There are only a few wedges with power supplies in crate 
#16. L00 Barrel 1 wedge 1 is one of them. We have tested the 
fix and the system appears to be stable. You should be able 
to turn on or off any part of the detector now.</pre>
<!-- Author: Doug B -->


<!-- Date: Thu Mar 14 17:52:55 2002 -->
We had an svx abort today at 15:31.  <a href= 
'/cgi/elog/elog.pl?nb=2002&action=view&page=218&frame=2&anchor=16:05:43'> 
See general elog entry. </a> (read all the way to the end)
<!-- Author: Eva -->


<!-- Date: Thu Mar 14 18:15:15 2002 -->
<pre>All the temperature log files have been moved to the /cdf/svx-data1/ disk.</pre>
<!-- Author: Saverio -->


<!-- Date: Fri Mar 15 02:12:32 2002 -->
LB0W3 L3 had External trips on VBIAS and AVDD and DVDD when trying 
to go from Standby to On.  Tried again, it happened again. 
Running it on Standby until someone can look at it in the morning.  (All else BIASED ok).
<!-- Author: SCN -->
<!-- Comment: Fri Mar 15 02;16;53 comment by...SCN -->
Attempted to put into "Problem database" as Incident, got  <pre>
Internal Server Error

The server encountered an internal error or misconfiguration and was unable to complete your request.

Please contact the server administrator, root@localhost and inform them of the time the error occurred, and anything you might have done
that may have caused the error.

More information about this error may be available in the server error log.
</pre>

Info was<pre>
Adding problem:


ID = unassigned

GROUP = Detector

NOTIFY = 

USER = nahn

DETECTOR = L00

WEDGE = B0W3

LAYER = L3

STATUS = new

TYPE = BIAS

ACTION = Incident

DESCRIPTION = LB0W3 L3 had External trips on VBIAS and AVDD and DVDD 

</pre>
Source <pre>
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML//EN">
<HTML><HEAD><TITLE>Add new entry to problem DB</TITLE>
</HEAD><BODY><body bgcolor="51d1d3"><H2>Adding problem:<hr></H2><H3>ID            = unassigned</H3><H3>GROUP         = Detector</H3><H3>NOTIFY        = </H3><H3>USER          = nahn</H3><H3>DETECTOR      = L00</H3><H3>WEDGE         = B0W3</H3><H3>LAYER         = L3</H3><H3>STATUS        = new</H3><H3>TYPE          = BIAS</H3><H3>ACTION        = Incident</H3><H3>DESCRIPTION   = <a href=
'/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=102&frame=2&anchor=02:12:32'>
LB0W3 L3 had External trips on VBIAS and AVDD and DVDD</a> 
</H3><hr>
<Form method="GET"
action="/cgi-bin/newproblemdb/DBupdate.pl"> 
<input type=hidden name=id       value=unassigned >
<input type=hidden name=group    value=Detector   >
<input type=hidden name=notify   value=   >
<input type=hidden name=user     value=nahn  >
<input type=hidden name=detsys   value=L00  >
<input type=hidden name=wedge    value=B0W3   >
<input type=hidden name=layer    value=L3   >
<input type=hidden name=status   value=new  >
<input type=hidden name=action   value=Incident>
<input type=hidden name=type     value=BIAS    >
<input type=hidden name=action   value=Incident    >
<input type=hidden name=description value="<a href=
'/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=102&frame=2&anchor=02:12:32'>
LB0W3 L3 had External trips on VBIAS and AVDD and DVDD</a> 
"    >
<input type=submit value="Commit"></Form>
<hr>
<A HREF="/cgi-bin/newproblemdb/DBmain.pl"> Return to main
</pre>


<!-- Date: Fri Mar 15 02:18:56 2002 -->
</A> Looks like the source for the page doesn't close its 
link
<!-- Author: SCN -->


<!-- Date: Fri Mar 15 08:59:37 2002 -->
</a> 
<pre>Monitoring Report on LB0W3L3. 
This wedge had in the past a history of trips on VBias1 
sure enough this was one of them, although it was reported as an external trip. The bias voltage of this was reduced to 130 V,  
the proposed cure is to raise the current limit above the  
present hardwired 30 uA  
 
Fri Mar 15 01:54:41 2002  
56  1  12291   125.90    29.73 uA <-- channel that tripped 
59  1    515    36.90     2.81 uA <-- channel that reported trip 
 
To be checked: normal values of current during data taking. 
 
Proposed actions: 
- improve the GUI log report to include this kind of trips 
   on Vbias1 
- increase the sw current limit for this "ladder" 
</pre>
<!-- Author: Saverio -->
<!-- Comment: Fri Mar 15 15;14;34 comment by...Andy H. -->
I checked the PSMon trip log files and sure enough the
overcurrent trip bit was set for VBIAS1 while the ext. trip
bit was set for the other three voltages.  I thought Andrew
and Doug fixed this trip-reporting bug last week but maybe it
crept back in....
<!-- Comment: Fri Mar 15 17;05;36 comment by...SCN -->
This ladder tripped again.  The software limit of 30
cannot be increased, so I walked up the Bias1 and
found it initialiiy draws 20 uA at 120 V.  With Chris's approval
I left it there and am putting the 120 V in the 
hdwdb and downloading such that it doesn't trip again.
<!-- Comment: Fri Mar 15 21;33;56 comment by...SCN -->
Whooops-I somehow forgot to load the CAENvolts.dat I generated.
So after the <a href=
'/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=102&frame=2&anchor=20:22:24'>trip</a> it seems
to have come back up all the way to 135.  Anyway, CAENvolts.dat is now updated, so the next time we cycle it to standby and
back up it should come up to 120. 

<!-- Date: Fri Mar 15 12:18:07 2002 -->
this is a test: second attempt to send e-mail entries
<!-- Author: sav -->


<!-- Date: Fri Mar 15 12:50:48 2002 -->
<p><font size=+1> D-mode Calibration Job Started </font>
<p><pre>
Job id            : 105
Calibration type  : standard
Run period tag    : Mar_2002
DPS-off run       : 140900
DPS-on run        : 140899
Requested by      : Igor
Main process id   : 1126461
</pre>
<!-- Author: CDF silicon D-mode calibration job server v1.3 -->


<!-- Date: Fri Mar 15 13:19:09 2002 -->
<p><font size=+1> D-mode Calibration Job Started </font>
<p><pre>
Job id            : 106
Calibration type  : standard
Run period tag    : Mar_2002
DPS-off run       : 140980
DPS-on run        : 140979
Requested by      : giolo kim
Main process id   : 1168482
</pre>
<!-- Author: CDF silicon D-mode calibration job server v1.3 -->


<!-- Date: Fri Mar 15 13:35:00 2002 -->
<p><font size=+1> D-mode Calibration Job Finished </font>
<p><pre>
This is a computer-generated silicon D-mode calibration status report.
Silicon D-mode calibration job 106 FAILED.

Job info
--------
Calibration type : standard
DPS-off run      : 140980
DPS-on run       : 140979
Requested by     : giolo kim
Submitted        : 2002-03-15 11:18:30
Completed        : 2002-03-15 11:34:28
Status           : FAILURE

Last processing stage reported : checking silicon configuration
Failure diagnostics :
error {Invalid request status "" for run 140980 from http://nglas05.fnal.gov/svx/bias_run_txt_cgi.pl?run_number=140980}
Exiting.
</pre>
<!-- Author: D-mode script run_calib_analysis.tcl -->




<!-- Date: Fri Mar 15 15:30:10 2002 -->
<pre>MONITORING REPORT for incident # 327 (still unreported here) 
 
SVX SB1W1 L2 ladder tripped on External trip on 
the bias channel while in stand-by. during a global iFIX 
ON-&gt; SBY transition. 
 
GUI-spy file 
New time 49964 Fri Mar 15 13:52:44 2002 
 455  2 -32765     1.80     1.38  &lt;-- bias previous ch.  
 456  1      3     0.61     0.00  
 457  1      3     0.00     0.00  
 458  1    515     0.00     0.00  &lt;-- tripped channel 
 
As you can see the AVdd ch and DVdd channels have been turned OFF 
(they were on in the previous reading) As a consequence 
the BIAS tripped as "external". 
 
GUI log file: 
Fri Mar 15 13:51:04 CST 2002     IFix -  success: L00 to STANDBY   
Fri Mar 15 13:51:53 CST 2002     IFix -  success: SVX Barrel 1 to STANDBY   
Fri Mar 15 13:52:44 CST 2002     TRIP: SVX  B1  W1 External Trip 
Fri Mar 15 13:52:44 CST 2002     IFix -  success: SVX Barrel 2 to STANDBY   
Fri Mar 15 13:53:37 CST 2002     IFix -  success: SVX Barrel 3 to STANDBY   
Fri Mar 15 13:54:45 CST 2002     IFix -  success: ISL to STANDBY   
Fri Mar 15 14:16:25 CST 2002     ALARM:   ISL  B3  W0  L4 is reported OFF, but low/high voltage is above 2/5 V  
Fri Mar 15 14:19:13 CST 2002     success: Channel2 SVX B1 W1 to STANDBY 
Fri Mar 15 14:20:49 CST 2002     success: Channel2 SVX B1 W1 ON 
Fri Mar 15 14:21:36 CST 2002     success: Channel2 SVX B1 W1 to STANDBY 
 
This was successfully turned SBY and ON by Gino & Steve 
To the PS working group.</pre>
<!-- Author: Saverio -->
<!-- Comment: Fri Mar 15 18;15;03 comment by...SCN -->
yeah, I put it in the Problem DB but forgot here.


<!-- Date: Fri Mar 15 18:50:59 2002 -->
<pre>./cratematch.pl updated with kludge for L00 channel 4 that 
should not appear in the list of PS-inhibited channels now.</pre>
<!-- Author: Saverio -->


<!-- Date: Fri Mar 15 19:11:07 2002 -->
<h3>Towards the end of 00f3</h3> 
Statement of the problem<P>  Various HDIs in the Silicon system 
have the annoying habit of spitting out 12KB of garbage data 
in the form of "Channel 00 Data 0xF3" over and over and over again. Some do it all the time, some only rarely, and it seems 
to be correlated with other misbehaviours of ladders, like dropping readout.  This causes deadtime due to Silicon readout 
(strangely masked as SVT procesing time) at L1A rates of 
1/240 uS ie about 4 kHz and higher, as well as overly large events etc.  The confusing part was that the Fib should never produce more than 4 KB on any channel, as that is about how many readout clocks we send.  
<P> 
We went over to FCC and used Gino's AVDD2 trick to produce a 
bad ladder to study 00f3.  We learned <ul> 
<li> There is some bug in the Fib grey code counter for  
Readout BE clock such that when it is written with a value greater than 4095 (which is required for ISL RA pedestals) the Fib actually counts to 12K 
(240 uS) or so, independent of what you wrote, and then truncates.  If you set it less than 4096, the Fib truncates where it is suppossed to. 
<li> The 00f3 problem changes characteristics with Sparsification  
setting. <ul> 
<li> In Read All mode, you get out OBDV for all the 
channnels in the good chips and then no more OBDVs. 
In this case the Fib stops sending BE clocks something like 
2.5 uS after the OBDVs stop 
<li> In Nearest Neighbor mode, the you get an OBDV back for  
every single one the the BE Clocks you send, all the way out to 12 K.  Typically the data you get is 00 (where every other 
00 becomes f3 due to the Fib Calc RAM) but sometimes you get other data.  This explains why the Fib doesn't cut off-OBDVs 
<B>DO NOT STOP COMING</B>.   
</ul> 
Gino speculates that this difference is due to some of the 
digital logic in the Chip in fact using Analog power, and perhaps Igor can tell us more. 
Probably previous tests of the length of OBDV did not use 
Nearest Neighbor mode. 
</ul> 
With this in mind, at (almost) the beginning of this store, 
we changed the SvxSet parameter Readout length from 4300 to 
4095, only for   As a result, our total Read Busy length dropped 
from 240 uS to 80 uS, where it is expected to be.   
We could reduce this number further when we decide what our maximum instantaneous occupancy to be, but this will not be important until the L1 trigger rate gets to be ~ 1/80 uS, 
except for the fact that we now get 4K of 00f3 on the bad ladders.  Seems to me it might be reasonable to limit the occupancy of any HDI to 1 (2) kB, which is 25(50)% event occupancy for ISL, and more for all others.  Maybe David's study 
could be looked at to confirm this. 
<!-- Author: SCN, Gino, Ken -->


<!-- Date: Fri Mar 15 20:22:24 2002 -->
<h3>Yikes!</h3>  <a href= 
'/cgi/elog/elog.pl?nb=2002&action=view&page=222&frame=2&anchor=19:10:37'> 
Clock problems</a>!  
<pre> 
Fri Mar 15 19:37:40 CST 2002     TRIP: L00  WEST  W3 DVDD3 OverCurrent 
Fri Mar 15 19:37:51 CST 2002     TRIP: SVX  B1  W4 DVDD2 OverVoltage 
Fri Mar 15 19:37:52 CST 2002     TRIP: SVX  B1  W5 DVDD2 OverVoltage 
Fri Mar 15 19:38:15 CST 2002     Software protection trip: High DVDD Current  SVX B1 W4 L4 
Fri Mar 15 19:38:17 CST 2002     Software protection trip: High DVDD Current  SVX B1 W5 L3 
Fri Mar 15 19:38:18 CST 2002     Software protection trip: High DVDD Current  SVX B1 W5 L4 
Fri Mar 15 19:38:19 CST 2002     Software protection trip: High DVDD Current  SVX B5 W0 L2 
Fri Mar 15 19:38:20 CST 2002     Software protection trip: High DVDD Current  SVX B5 W0 L4 
Fri Mar 15 19:38:21 CST 2002     Software protection trip: High DVDD Current  SVX B5 W1 L2 
Fri Mar 15 19:38:22 CST 2002     Software protection trip: High DVDD Current  SVX B5 W1 L3 
Fri Mar 15 19:38:23 CST 2002     Software protection trip: High DVDD Current  SVX B5 W1 L4 
Fri Mar 15 19:38:35 CST 2002     TRIP: SVX  B1  W4 DVDD2 OverVoltage 
Fri Mar 15 19:38:35 CST 2002     TRIP: SVX  B1  W4 DVDD2 OverVoltage 
Fri Mar 15 19:38:35 CST 2002     TRIP: SVX  B1  W5 DVDD3 OverVoltage 
Fri Mar 15 19:38:35 CST 2002     TRIP: SVX  B1  W5 DVDD3 OverVoltage 
Fri Mar 15 19:38:35 CST 2002     TRIP: SVX  B1  W5 DVDD3 OverVoltage 
Fri Mar 15 19:38:35 CST 2002     TRIP: SVX  B5  W0 DVDD1 OverCurrent 
Fri Mar 15 19:38:35 CST 2002     TRIP: SVX  B5  W0 DVDD1 OverCurrent 
</pre> 
After getting paged for these trips, I talked the Ace through 
putting the SRC on its internal Clocks while they fix CDF Clock. 
The list appears not to be growing.  When Clock fix is in, we'll 
attempt to turn it all back one (perhaps send to Standby, then back to On).  If another glitch like that happens, we'll  
turn it all off until the clock is declared sane...
<!-- Author: SCN -->
<!-- Comment: Fri Mar 15 21;35;41 comment by...SCN -->
Clock is back.  Talked Ace through turning on of LB0W3 L3 and
wedges SB1W4,SB1W5, SB5W0, SB5W1.  All came up to bias without trouble.  CDF now integrating Silicon to resume running. 

<!-- Date: Sat Mar 16 00:16:22 2002 -->
<p><font size=+1> D-mode Calibration Job Finished </font>
<p><pre>
This is a computer-generated silicon D-mode calibration status report.
Silicon D-mode calibration job 105 FAILED.

Job info
--------
Calibration type : standard
DPS-off run      : 140900
DPS-on run       : 140899
Requested by     : Igor
Submitted        : 2002-03-15 10:50:08
Completed        : 2002-03-15 22:14:52
Status           : FAILURE

Last processing stage reported : comparing to the reference calibration
Failure diagnostics :
The calibration failed the following reference comparison criteria:

           Cut Name    Sensor Set   Cut Value   Data Value
-------------------    ----------   ---------   ----------
dps_off_ped abs max    SVX_PHI      0.5         0.850035  
 dps_on_ped abs max    SVX_PHI      0.2         0.3906    

Reference calibration runs are 139904 (DPS off) and 139902 (DPS on)
</pre>
<!-- Author: D-mode script run_calib_analysis.tcl -->


<!-- Date: Sat Mar 16 02:39:18 2002 -->
<p><font size=+1> D-mode Calibration Job Started </font>
<p><pre>
Job id            : 107
Calibration type  : standard
Run period tag    : Mar_2002
DPS-off run       : 141015
DPS-on run        : 141014
Requested by      : Naho Tanimoto
Main process id   : 2089687
</pre>
<!-- Author: CDF silicon D-mode calibration job server v1.3 -->


<!-- Date: Sat Mar 16 02:40:50 2002 -->
<p><font size=+1> D-mode Calibration Job Finished </font>
<p><pre>
This is a computer-generated silicon D-mode calibration status report.
Silicon D-mode calibration job 107 FAILED.

Job info
--------
Calibration type : standard
DPS-off run      : 141015
DPS-on run       : 141014
Requested by     : Naho Tanimoto
Submitted        : 2002-03-16 00:38:49
Completed        : 2002-03-16 00:40:03
Status           : FAILURE

Last processing stage reported : checking silicon configuration
Failure diagnostics :
error {Invalid request status "Content-type: text/html" for run 141015 from http://nglas05.fnal.gov/svx/bias_run_txt_cgi.pl?run_number=141015}
Exiting.
</pre>
<!-- Author: D-mode script run_calib_analysis.tcl -->



<!-- Date: Sat Mar 16 03:11:36 2002 -->
Bias OVC trip SB1W4 L4.  Turned it back on.
<!-- Author: SCN -->
<!-- Comment: Sat Mar 16 04;07;51 comment by...SCN -->
Tripped again 7 minutes later.  Store almost over, so 
turned it to standby and had them ignore trigger inhibit from
SVX while I investigate.  Had a hell of a time trying to find
some way of plotting Bias currents-Auke's tool doesn't seem to 
show me any trips, as far as I can tell, so I must be doing something wrong.  Figure out how to dump from 20020316_si
so can look at last 30 samples before a voltage/current of 0.00 for channel 488 = SB1W3 L4 BIAS<pre>
> grep -e" 488  " 20020316.si_ | grep -B30 -e"  0.00"
 488  0 -32765    36.90   304.00
 488  0 -32765    36.90   304.00
 488  0 -32765    36.90   305.00
 488  0 -32765    36.90   305.00
 488  0 -32765    36.90   303.00
 488  0 -32765    36.90   303.00
 488  0 -32765    36.90   304.00
 488  0 -32765    36.90   304.00
 488  0 -32765    36.90   305.00
 488  0 -32765    36.90   305.00
 488  0 -32765    36.90   306.00
 488  0 -32765    36.90   306.00
 488  0 -32765    36.90   305.00
 488  0 -32765    36.90   305.00
 488  0 -32765    36.90   304.00
 488  0 -32765    36.90   304.00
 488  0 -32765    36.90   305.00
 488  0 -32765    36.90   305.00
 488  0 -32765    36.90   388.00
 488  0 -32765    36.90   388.00
 488  0 -32765    36.90   367.00
 488  0 -32765    36.90   367.00
 488  0 -32765    36.90   347.00
 488  0 -32765    36.90   347.00
 488  0 -32765    36.90   369.00
 488  0 -32765    36.90   369.00
 488  0 -32765    36.90   380.00
 488  0 -32765    36.90   380.00
 488  1  12291    36.90   391.00
 488  1  12291    36.90   391.00
 488  1   4099     0.00     0.00
 488  1   4099     0.00     0.00
 488  2 -32765     2.00     0.00
 488  2 -32765     2.00     0.00
--
 488  0 -32765    36.90   317.00
 488  0 -32765    36.90   317.00
 488  0 -32765    36.90   304.00
 488  0 -32765    36.90   304.00
 488  0 -32765    36.90   300.00
 488  0 -32765    36.90   300.00
 488  0 -32765    36.90   297.00
 488  0 -32765    36.90   297.00
 488  0 -32765    36.90   422.00
 488  0 -32765    36.90   422.00
 488  0 -32765    36.90   431.00
 488  0 -32765    36.90   431.00
 488  0 -32765    36.90   311.00
 488  0 -32765    36.90   311.00
 488  0 -32765    36.90   306.00
 488  0 -32765    36.90   306.00
 488  0 -32765    36.90   300.00
 488  0 -32765    36.90   300.00
 488  0 -32765    36.90   293.00
 488  0 -32765    36.90   293.00
 488  0 -32765    36.90   347.00
 488  0 -32765    36.90   347.00
 488  0 -32765    36.90   318.00
 488  0 -32765    36.90   318.00
 488  0 -32765    36.90   302.00
 488  0 -32765    36.90   302.00
 488  0 -32765    36.90   311.00
 488  0 -32765    36.90   311.00
 488  0 -32765    36.90   238.00
 488  0 -32765    36.90   238.00
 488  1   4099     0.00     0.00
 488  1   4099     0.00     0.00
 488  2 -32765     2.00     0.00
 488  2 -32765     2.00     0.00
 488  2 -32765     2.00     0.00
</pre>
So all of the sudden the current gets jumpy and then trips.  No real
idea what this means, but Mario claimed (and I haven't checked the beam was fairly stable.)  Anyway, it doesn't to mee look like a pinhole, so I guess we'll just try again at the start of
the next store.


<!-- Date: Sat Mar 16 06:37:21 2002 -->
<h3>This ladder is starting to becmoe annoying</h3> 
SB1W4 L3 Bias tripped a<a href= 
'/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=102&frame=2&anchor=03:11:36'>again</a>  
gain, when turning everything back on to start the store.  I had 
Mario walk it up to 35 V (nominal is 37), and it seems to be slowly decaying from 320 uA.  I promised that next time 
it tripped we'd take it out....<P> 
By the way, I find the quickPSview tool quite useful 
(except for a little write protection issue) but I also want 
a trip finder like the grep which shows the last few minutes  
before a trip.  This can help an expert at home decide what to do, and is quicker and more robust that anu of the plotters 
we have.
<!-- Author: SCN -->