<!-- Title: 14:31:36  Tue Sep 25 2001 -->
<!-- Crewchief: L2 -->
<!-- Op1: SVT -->
<!-- Op2: &nbsp; -->
<!-- Op3: &nbsp; -->
<!-- Op4: &nbsp; -->
<!-- Op5: &nbsp; -->
<!-- Op6: &nbsp; -->
<!-- Notes: -->
<pre>Can we acheive jet and svt cutting for normal data taking 
before the end of the week?</pre>


<!-- Date: Tue Sep 25 14:42:46 2001 -->
<pre>L2 Meeting 9/24/01 
 
Clist - Heather will test her new electron code 
 
SVT - will do more SVT cutting tests including alpha in the run 
        (see previous log book entry for results) 
      The SVT system can generate parity for the L1 trigger bits 
        and insert this into the SVT EOE word. This will be done 
        in the next few days. 
 
Track boards - Need to test modified boards, but can do it 
      without beam. Board 6 has some problems to be debugged. 
 
XTRP - the new firmware has solved the sync error problem. However one of the new boards has a sync error for data local 
to that board. This shows up every few million events. Nathan 
needs time without beam to work on it. 
 The XTRP board can also set the error bits in the Track EOE word 
so the alpha can force a L2 timeout. 
 
We will make a L2Error trigger which will be used to keep track 
of non-fatal errors. 
 
It would be very useful to use the bottom L2 crate as a test 
crate during normal datataking. It would be included in the 
run partition, but would always send L2 rejects. That way a new 
board wouldn't interfere with the upper crate, but would allow 
beam data and triggers to be used for tests. This crate would 
either create a second TL2D bank, or a L2 diagnostic bank which 
could hold the previous N events worth of data. That way data 
from rejected events would also be available. 
It will take a couple of days to write a general executable for 
this purpose, so this will be done during the shutdown.  
</pre>
<!-- Author: Stephen -->


<!-- Date: Tue Sep 25 21:00:01 2001 -->
<ul><pre><p> 
<b>SVT work 9/25</b> 
<li>Marco's program now histograms more GB output; automatically 
loads GB beamspot from Luciano's program output. 
<li>Alex installed Giovanni's new fit constants; tested in svtsim; now installed as default mapset; tested once through 
coldstart (which rewrites TF FRAMs) 
<li>Lester is installing/testing new SRC PROM 
<li>Rebooted all SVT crates to get Marco's latest/greatest 
</pre></ul>
<!-- Author: Bill, Alex -->
<!-- Comment: Fri Sep 28 02;45;25 comment by...Giovanni -->
Specifically, the new fit constants are:<A HREF="http://b0dau30.fnal.gov:8000/cgi-bin/cvsweb.cgi/svt_config/data/0123X_wide_gconbeam/?hideattic=1&sortbydate=0">0123X_wide_gconbeam</A>
<!-- Date: Wed Sep 26 09:04:46 2001 -->
<center><a href='/cgi/elog/det-system-elog.pl?nb=l2&action=view&page=-358&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=l2&action=view&page=-358' width='300'></a><a href='/cgi/elog/det-system-elog.pl?nb=l2&action=view&page=-357&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=l2&action=view&page=-357' width='300'></a></center>
<!-- Author: hray -->
<!-- Comment: Wed Sep 26 09;20;42 comment by...hray, pwitt -->
<ul>
<li>So, for the first feat Peter Wittich and I performed at 5 am -> LOCOS in b0l2cl01 was changed from SN7 to SN10.  This may help with the eta phi errors
<li>The second feat was the testing of the new CLIST board.  Monica said she had seen these problems before - this is the infamous VME error that was thought to have been fixed.  So, with _only_ the new CLIST (SN2) in the de crate, with the new prom in place, we tried plugging the board in and doing a CDFVME read.  These are the results (see pic above) :  Monica thought we should see xe740 if the vme is okay, x1 or x2 if it is not.  We don't see either of these - unless the xe880 is correct in this first read?
<listing><font size=+.5>
A32:D64		0xc30e880021476c read from address 0x70400000	
A32:D32		0xffffffff read from address 0x70400000
A24:D32		0xffffffff read from address 0x70400000
A32:D16		0xffff read from address 0x70400000
A24:D16		0xffff read from address 0x70400000
A16:D16		0xffff read from address 0x70400000
</listing></font>
<br>
<li>The third feat : Peter tried several runs with his error handling code.  Results : "monitoring code agrees with the debug code but we're not able to read out any of the cluster or l1 data with this version of the code".  He's still here across from me working on stuff
<li>I also took several runs trying to reproduce the sync error without beam.  I'll consult with Monica before putting into elog - they may have not been relevant due to some code changes
<li>we were plagued by bc mismatch errors which, as I noted last week, do go away if you push on the prom on CLIST really hard and wiggle it a bit.  Apparently our connector is wearing out.  
</ul>


<!-- Date: Thu Sep 27 10:46:13 2001 -->
<pre>Isolation:  our goal today was to confirm the zero-isolation 
energy problem and determine if it was in the alpha or 
alpha software  or in the Isolation hardware.  By unplugging 
a DCAS cable we forced non-zero energies and then  
looking at the data bits on MB we saw that there were 
times when the bits went to zero and shouldn't have. 
So it's in the Isolation hardware.   Next time we'll 
use the spare Isolist card with the debugging wires.</pre>
<!-- Author: Steve Kuhlmann -->


<!-- Date: Thu Sep 27 17:31:56 2001 -->
<pre>We successfully did a test run for about an hour with 
L2 cutting on Jets. This was using the new error handling 
code. There were no timeout errors until at the end we 
unplugged the clique cable going into clist. 
 The only catch is that we needed to HRR to get the run 
properly going again. As soon as the new physics table is made, 
then we can regularly cut on Jets. 
 
             </pre>
<!-- Author: Stephen -->


<!-- Date: Fri Sep 28 00:25:52 2001 -->
<pre>The SVT beam time for today has been rescheduled to 2 am 
so I will wait until then for loading Giovanni's new 
constants. In the mean time I will try to  
measure the SVT timing for each HF </pre>
<!-- Author: Alex -->
<!-- Comment: Fri Sep 28 02;56;54 comment by...Alex -->
<pre>"giovanni's new constants" refers to http://www.pi.infn.it/~punzi/SVT_config.html
0123X_regbm_gconbm

Unfortunately the CRC generation core dumps on
0123X_widebm_gconbm
Could some kind of error in the ss map produce this
result?

</pre>


<!-- Date: Fri Sep 28 06:27:55 2001 -->
<center><a href='/cgi/elog/det-system-elog.pl?nb=l2&action=view&page=-359&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=l2&action=view&page=-359' width='300'></a><a href='/cgi/elog/det-system-elog.pl?nb=l2&action=view&page=-360&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=l2&action=view&page=-360' width='300'></a></center>
<!-- Author: hray -->


<!-- Date: Fri Sep 28 07:11:23 2001 -->
<ul> 
<font color='blue'>List of things Monica and I did last night:</font> 
<li>On the new CLIST (SN2) we saw EOE was always low.  The receiver that sees this signal from CLIQUE was always deasserted so we tried lifting a pin.  This fixed the EOE problem but now the latch_en0 is never set (ie CLIST doesn't see any clusters coming in).  DCAS is clearly clustering, so this is another problem.  Monica will take this back with her to Michigan today 
<li>We tried to reproduce sync errors using old CLIQUE prom 9_16, Physics_I_0_01[9], alpha cutting, 6 L3 farms, 200 debug mode 
Trigger LA on DONE0 being set (error bit) 
<listing><font size=+.5> 
127773 - see 0 MB words sent from CLIST right away 
127774 - again 0 MB words, HRR doesn't fix, pause and resume and it goes away 
127775 - again 0 MB words, trigger on L1A on LA and see events that appear quite 
	normal - not sure why the error bit is always set  
127776 - trigger LA on STLOAD and MBDONEOUT and ran with no errors 
 
We then tried loading the Physics_I [7] which I had used before with debug program.  It wasn't seen in RC even though 
the DB said it was valid and visible.  We tried loading it by 
hand, and when we finally had sucess the system was 
taken from us (circa 11 pm or so) 
</listing></font> 
<br> 
<font color='blue'>Things we did this morning</font> 
<li>Started off trying to once again reproduce the sync error, loading Physics_I[7]_debug  by hand, now have CLIQUE prom version 4 in (real old one).  using 6 L3 farms, alpha cutting, trigger on DONE0 bit 
<listing><font size=+.5> 
127790 - debug 200 and see get 0 MB errors right away, HRR doesn't fix 
127791 - try debug 136 with Physics_I[9] trigger table instead, and we still get 0 MB words at the start 
127792 - try a different physics table -> Physics__01[28,203] (used last night for physics running) 
	with 136 debug - NO ERRORS! 
 
We conclude there is something wrong with the two I physics tables Stephen compiled a few weeks ago to have this special error handling (debug mode 200).   
We try switching to a D table, error mode 136 and triggering LA on DONE0, so that all events will be written to an I stream 
 
127793 - run Phyiscs_D[5,188], debug 136 -> <b>see above pictures :</b>  
	We get these never seen before messages in minicom window (L pic) and _no_ debug message 
	pause run to set debug for sure to 136, resume and HRR and still don't see any 
	debug messages.  Actually, as of last week on a HRR you would see the Prescale messages  
	scroll again in the minicom window.  Now that doesn't happen, so if we change PS or debug 
	there is no way to know if the HRR picked it up.  I noticed this last night for several of 
	our runs - could it be the bad physics tables? 
127794 - change to another table, also in L1/L2 so it should be decoupled and have an I 
	stream : Physics_0_01[42,188].  Change Jet5 PS at L1, debug 136 and now we see the debug message! (R picture) 
</listing></font> 
<li>from this point on we ran with 127794 configuration, ending each run around 100 K or so - because even with I stream only so many events get written to look area.  We've had the sync error in the past sometimes at the very beginning of a run, especially after ending/cs many times.  still waiting to find the error .. plagued by TSI BTO/RC stopping at the L3 magic numbers/need to cleanup EVB 
</ul>
<!-- Author: hray, tecchio -->
<!-- Comment: Fri Sep 28 09;04;00 comment by...monica and heather -->
<pre>Runs 127797/798/801 and 803 were taken with the configuration above. Never any error caught by debug monitor. MOD_DONE0 on LA triggered once at the end of 127798.
Finally 127804 was taken after we changed DCAS in slot 9 of b0l2cl04, found to be the cause the cluster EM energy Overflow bit being always high.</pre>


<!-- Date: Fri Sep 28 13:12:48 2001 -->
We noticed a pin on the breakout termination board (Data 108) which may have been touching another pin (Data 109).    We've 
seen the Logic Analyzer bend such thick pins before since its pods are heavy.   It would be a good idea to strain-relief it so the board does not have to support its weight and to check the pins after disconnecting it.  
<!-- Author: David  and Matt  -->

<!-- Date: Fri Sep 28 22:00:38 2001 -->
Tracking update<p>  
After some hard work by a lot of people, L2 tracking is now in the following state.<p>  
1.  Over the past couple of stores we have been seeing a large number of disagreements in d0 and 
other SVT quantities between TL2D and SVTD.  These disagreements only manifested under beam 
conditions, and not with fake SVT track test patterns, even at high rates.  New plots in TrigMon 
revealed that SVT was putting the unbeam-corrected values into L2 and the beam-corrected values into 
the SVT readout.  Of course, this would not show up without the SVX sending real tracks to SVT.  
Tonight Bill and Alex added a Merger board to SVT06 and now both TL2D and SVTD receive the 
beam-corrected data.  Before and after plots are below.
<!-- Author: Matt -->


<!-- Date: Fri Sep 28 22:03:26 2001 -->
<center><a href='/cgi/elog/det-system-elog.pl?nb=l2&action=view&page=-361&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=l2&action=view&page=-361' width='300'></a><a href='/cgi/elog/det-system-elog.pl?nb=l2&action=view&page=-362&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=l2&action=view&page=-362' width='300'></a></center>
<!-- Author: Matt -->
<!-- Comment: Fri Sep 28 22;04;13 comment by...Matt -->
Left plot: BEFORE.  Right plot: AFTER.


<!-- Date: Fri Sep 28 22:08:18 2001 -->
2.  This afternoon between the stores David and I traced the stuck chi-squared bit 3 in SVTlist board 7 to a bad connection between buffer chip S2 and the backplane connection pin C24 to MBdata 108.  This turned out to be a bad via and it was fixed this afternoon.  TrigMon plots below confirm that the the problem is gone.
<!-- Author: Matt -->

<!-- Date: Fri Sep 28 22:19:37 2001 -->
<center><a href='/cgi/elog/det-system-elog.pl?nb=l2&action=view&page=-363&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=l2&action=view&page=-363' width='300'></a><a href='/cgi/elog/det-system-elog.pl?nb=l2&action=view&page=-364&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=l2&action=view&page=-364' width='300'></a></center>
<!-- Author: Matt -->
<!-- Comment: Fri Sep 28 22;19;53 comment by...Matt -->
BEFORE.


<!-- Date: Fri Sep 28 22:20:47 2001 -->
<center><a href='/cgi/elog/det-system-elog.pl?nb=l2&action=view&page=-365&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=l2&action=view&page=-365' width='300'></a><a href='/cgi/elog/det-system-elog.pl?nb=l2&action=view&page=-366&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=l2&action=view&page=-366' width='300'></a></center>
<!-- Author: Matt -->
<!-- Comment: Fri Sep 28 22;21;03 comment by...Matt -->
AFTER.


<!-- Date: Fri Sep 28 22:32:01 2001 -->
<p> 
3.  Nathan has firmware in XTRP that, in the event of a collision between the token going around the XTRP boards to pass tracks to SVT/L2 and the XTRD bank readout on a L2 accept, the data going to SVT/L2 "wins" and the XTRD readout is corrupted for that event.  This keeps SVT/XTRP/L2 all 'n sync, and allows the XTRD readout to be on.  This will show up as a mismatch in the number of tracks between TL2D and XTRD, usually only by 1 or 2 tracks.<p> 
Nathan has also moved the two bad XTRP cards to slots 4 and 5. 
The TrigMon plots for XTRPlist were updated to account for the location of bad/masked out XTRP cards.  Cards can be skipped in TrigMon in the TL2DMonitor talk-to.  The plots below show that the XTRP data arrives in TL2D with a high degree of accuracy.
<!-- Author: Matt -->


<!-- Date: Fri Sep 28 22:38:29 2001 -->
<center><a href='/cgi/elog/det-system-elog.pl?nb=l2&action=view&page=-367&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=l2&action=view&page=-367' width='300'></a><a href='/cgi/elog/det-system-elog.pl?nb=l2&action=view&page=-368&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=l2&action=view&page=-368' width='300'></a><a href='/cgi/elog/det-system-elog.pl?nb=l2&action=view&page=-369&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=l2&action=view&page=-369' width='300'></a></center>
<!-- Author: Matt -->
<!-- Comment: Fri Sep 28 22;39;59 comment by...Matt -->
One mismatch between the number of tracks in XTRD and TL2D.  Otherwise, Segment and Mini-Phi are identical.


<!-- Date: Fri Sep 28 22:41:01 2001 -->
<center><a href='/cgi/elog/det-system-elog.pl?nb=l2&action=view&page=-370&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=l2&action=view&page=-370' width='300'></a><a href='/cgi/elog/det-system-elog.pl?nb=l2&action=view&page=-371&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=l2&action=view&page=-371' width='300'></a></center>
<!-- Author: Matt -->
<!-- Comment: Fri Sep 28 22;45;24 comment by...Matt -->
XTRPlist board 3 has a low level of errors in pT bit 4 between XTRD and TL2D.  The bins in the pT mismatch plot are from the entire 920 events sampled by TrigMon in run 127841, giving a rough error rate of 4%.  Other XTRPlist boards will be swapped in to test if this is on the L2 or XTRP side of the cable.


<!-- Date: Fri Sep 28 23:11:08 2001 -->
<p> 
Known problems<ul> 
<li>Over long runs under beam conditions, we are still seeing the sync error pattern in BC/L2buffer plots at a very low level in both XTRPlist and SVTlist.  It is unclear whether these errors are from XTRP, SVT, or the tracklist boards themselves.  We hope that the error handling code will allow us to easily trace these errors, without us needing to take large amounts of beam time for tests. 
<li>SVTlist board 6 (our only SVTlist spare at Fermilab) appears to never take BOSS or send data to the alpha.  This board should first be checked without beam. 
<li>Single bit errors such as the XTRP pT bit above.  These errors can be studied without beam. 
</ul>
<!-- Author: Matt -->


<!-- Date: Sat Sep 29 07:51:57 2001 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=l2&action=view&page=-372&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=l2&action=view&page=-372  width='300' align='top'></td><td>rates with L2_TORTURE[3,188] after changing L1 MBIAS and Jet0.5 PS to 0 (ie masked them out).  Get healthy rates, low DT, and many  many flashing blue lights on DCAS</a></td></tr></table>
<!-- Author: hray -->


<!-- Date: Sat Sep 29 08:39:11 2001 -->
<ul> 
My past 24 hours, an essay by Heather Lynn Ray 
<li>Tried to fix electron code/recompile TEST_ELECTRON_D table/run with electrons.  This requires making a few changes to the L2Gobal.java TriggerDB file.  When I checked the TriggerDB package out of the repository it wouldn't compile.  I sent mail to Peter Wilson and Alexei and am waiting to hear something fruitful 
<li>Changed LOCOS in b0l2cl00 from SN8 to SN2 in attempt to fix wandering eta problems 
<li>Tried running with cosmics to reproduce sync error -> many problems. 
<li>Details of the runs to follow; summary is as such: there appears to be some very bad problems with running certain trigger tables in certain debug modes.  In the bad cases the Alpha pulls error bit right away and thinks CLIST sent 0 MB words while the LA (triggering on L1A) shows beautiful fine events.  I know this is a problem with certain trigger tables/debug modes.  I've tried switching trigger tables and debug modes in consecutive runs and seen the errors disappear.  I've sent email to Stephen, Peter Wilson, and Monica.  These tables/debug modes now giving errors worked last week so something had to have changed out from under me in the meantime. 
</ul>
<!-- Author: hray -->


<!-- Date: Sat Sep 29 09:06:33 2001 -->
<ul> 
The tests Monica and I ran where we saw the 0 MB words from CLIST ,error bit in Alpha being set, LA events pretty are <a href= 
'/cgi/elog/det-system-elog.pl?nb=l2&action=view&page=24&frame=2&anchor=07:11:23'> 
mentioned with a bit of detail above </a>  
<li>it should be mentioned for these runs that we tried Physics_I_0_01[7,175], Physics_I_0_01_debug[7], and Physics_I_0_01[9,206], all with various configurations of debug 136/200/none modes and all gave the 0 MB CLIST errors, where Physics_0_01[28,203] in debug 136 worked fine 
<br><br> 
<font color='blue'>this morning:</font> 
<br> 
->these runs were with alpha in tagging, 6 L3 farms, an old prom (v 4 something) in CLIQUE to look for sync errors with cosmics, no files being written to look area, becuase I just wanted to see if I could find the errors.   
<br> 
<b>several bad things happened for these runs, not all necessarily related to L2/0 MB CLIST words <a href= 
'/cgi/elog/elog.pl?nb=2001&action=view&page=713&frame=2&anchor=07:15:01'> 
see the owl shift log for the other details </a> </b> 
<br> 
<li>127869: L2_Rate[2,205], debug 136, 0 MB words from start, LA says events look good 
<li>127870: L2_rate[2,205], no debug, get other errors and have to end 
<li>127871: still using L2_rate[2,205] with no debug, other errors end run 
<li>127872: Cosmics_NoTracks[3,205] with no debug, other errors end run.  I switched tables because I wasn't yet sure if the other errors were TSI,EVB, or L2 related 
<li>127873: Cosmics_NoTracks[3,205] ran fine after reset/partition, no debug, LA set to trigger on DONE0 but never fires (ie no errors) 
<li>127875: Cosmics_NoTracks[3,205] with 136 debug.  This run works but rates are very low 
<li>127876: L2_TORTURE[3,188] with no debug, works fine 
<li>127877: L2_TORTURE[3,188] with debug 136 <b>Change MinBias and Jet0.5 PS at L1 to 0 to mask = LOTS OF BLUE LIGHTS FLASHING ON DCAS!</b> hint of the day: this way we can get the most bang for our buck with most events having clusters in dcas during cosmics.  the above pic is from this run.  end at 250K with no errrors.  We had noted before that stopping and starting the run several times appeared to cause sync errors more frequently at lower event numbers, so I try to do this again 
<li>127878: L2_TORTURE[3,188], end at 200K, see one bc mismatch but no sync error 
<li>127879: L2_TORTURE[3,188] w/ PS change, but get SM error at 5 K, have to end run and cleanup EVB 
<li>127880: currently running at over 400K, near the time when I have to give the system back so I'll keep this run going until that time. 
 
<BR> 
unless specifically stated, I only did a coldstart between each run, not reset or anything like that. I didn't cleanup EVB/L3. hope this is good enough  
</ul>
<!-- Author: hray -->


<!-- Date: Sat Sep 29 10:51:54 2001 -->
Briefly tested SVTlist board 6.  This board holds BOSS high (~4.0 V) the entire time it is in the L2 decision crate.  Checking local BOSS on the FPGA, it is always low (not asserted).
<!-- Author: Matt -->
<!-- Comment: Sat Sep 29 14;58;26 comment by...Matt -->
This problem was traced back to a bad chip in the middle of the BOSS arbitration mod.  It should be easily fixed.


<!-- Date: Mon Oct 1 04:38:27 2001 -->
<center><a href='/elog/notebooks/l2/Mon_Oct__1_2001_043757.ps'><img src='/cgi/elog/det-system-elog.pl?nb=l2&action=view&page=-374' ></a><a href='/elog/notebooks/l2/Mon_Oct__1_2001_043809.ps'><img src='/cgi/elog/det-system-elog.pl?nb=l2&action=view&page=-376' ></a></center>
<!-- Author: hray -->
<!-- Comment: Mon Oct  1 04;47;25 comment by...hray -->
<ul>So, the past 24 hours I've devoted to sleeping and eating.  I came in around 3 am instead of my alloted 9 pm to try to get the sync error with beam .... and they lost the beam around 3:15 or so.  Now I'm running with cosmics:
<br><br>
Clique is prom v_4, alpha tagging, debug 136, L2_TORTURE[3,188], changed L1 PS of MinBias and Jet0.5 to 0 to get lots of events with DCAS clusters.
<li>CLIST: 0=L1A, 1=HLNK_LE0, 2=EOE, 3=RCLK, 4=FIFO_EMPTY*, 5=LOC_REQ, 6=DSTROBE*,7=DDONE*, 8=LOC_BOSS, 9=MB_DONE_OUT, 10=CLIQUE_END, 11=CLIQUE_BUF0, 12=CLIQUE_BUF1, 13=WCLK, 14=WEN0, 15=WEN1 BACKPLANE: 16=STARTLOAD, 17=DONE0, 18=BUF0, 19=BUF1
<li>So far I haven't seen the scrolling "real" sync error.  This however is a one time only Clist buffer number mismatch error which sets the error bit.  LH plot is event before error, RH plot is event with error.  There is no L1A (as far as I could find) between the two graphs.  
<li>I've fixed and finalized the electron trigger in TriggerDB, offline validation, and alpha code.  There are a few problems here:  first, I've done something absolutely stupid and erased all my .log and .hbook files, thinking I could generate a whole new slew of them now that the validation code is fixed (as verified by a hardcopy output I went through 25 ev for line by line).  I didn't check first to see that the stupid run was still in the look area -> it's gone!  Second, I am unable to get the TDB code to compile from repository.  I can't regenerate the Electron Trigger Table until I get Alexei's help in this
</ul>

<!-- Comment: Mon Oct  1 07;13;31 comment by...hray -->
<ul>

<li>the above pic and all runs listed were taken with L2_TORTURE[3,188] with Clique prom v-4, alpha in tagging, debug 136, minbias and jet0.5 ps changed to 0 at L1.  I was trying to reproduce the sync error without beam (still!)
<li>127981 : get one single sync error - see above pic.  end at 800 K to try to restart.  I've found in the past that restarting a run a bunch of times in a given time window causes the sync error to happen more frequently, for fewer events
<li>127982 : end at 700K with no errors
<li>127984 : end at 100K with no errors - need to give system back for calibrations
</ul>


<!-- Date: Mon Oct 1 23:50:29 2001 -->
L2 cutting on jets<p> 
Run 128040 has 300k events with Physics_0_01[48,213] and L2 cutting on jets.  To go from L2 tagging and this trigger table to L2 cutting required both of us and several phone calls to Stephen.  The main problem was the L2 timeout error was called after 10-100 events from SVT-XTRPlist bc mismatches.  It appeared that the silicon was out of sync into SVT.  On the previous runs with the same system/trigger table, the silicon was also intergrated and staying in sync.  We resolved this problem by switching to the SVT sending a fake track pattern to L2.  Plots from L1interface and Clist are below.
<!-- Author: Bill and Matt -->
<!-- Comment: Tue Oct  2 09;05;03 comment by...Stephen -->
<pre>I think the previous events had L2 in tagging mode.
In that case, the error checking is not performed so the
alpha would not give timeout errors.
Perhaps the svx is more likely to go out of sync with L2 rejects?
</pre>
<!-- Date: Mon Oct 1 23:51:52 2001 -->
<center><a href='/cgi/elog/det-system-elog.pl?nb=l2&action=view&page=-377&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=l2&action=view&page=-377' width='300'></a><a href='/cgi/elog/det-system-elog.pl?nb=l2&action=view&page=-378&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=l2&action=view&page=-378' width='300'></a></center>
<!-- Author: Matt -->
<!-- Comment: Mon Oct  1 23;52;36 comment by...Matt and Bill -->
From L2 cutting on jets.  L1A = 270 Hz, L2A = 140 Hz.


<!-- Date: Tue Oct 2 03:00:24 2001 -->
I was unable to run my Electron trigger table tonight.  The alpha kept crashing at spot 65, which conincidentally now has error handling in place in a "protected" loop if you are not tagging..but I was tagging so that shouldn't have technically done any harm.  Either way, please read <a href= 
'/cgi/elog/elog.pl?nb=2001&action=view&page=722&frame=2&anchor=02:58:08'> 
this entry </a> for a summary in the shift elog, and the detailed trials I had are also listed there.  
<!-- Author: hray -->


<!-- Date: Tue Oct 2 09:01:50 2001 -->
 Changed DCAS in slot 10 of b0l2cl04 from 34 (ntower counter error) back to 2 (em overflow error)
<!-- Author: hray -->



<!-- Date: Tue Oct 2 23:35:46 2001 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=l2&action=view&page=-379&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=l2&action=view&page=-380  width='300' align='top'></td><td>XTRP is in sync!! </a></td></tr></table>
<!-- Author: a passer-by -->


<!-- Date: Wed Oct 3 03:04:44 2001 -->
<pre> I tried to test fiber connection between Reces and 
SMXR for preparing the test with beam. Tonight, Alpha could  
not even read one of the four reces boards 
at slot 18. I found it was caused by the bending  
DDONE* pin (I am sorry it is likely caused by myself).  
The pin does not touch to any other pins. I will request 
to fix the pin today.</pre>
<!-- Author: Masa -->


<!-- Date: Wed Oct 3 12:44:37 2001 -->
<pre>Fred Lewis came and fixed the bending pin. 
I want to try the same test again tonight. 
This is for making sure the SMXR-Reces connection is ok 
before the test with beam, since the given time with beam 
is limited ant I want to use the time effieicntly as much  
as possible. 
   
 
</pre>
<!-- Author: Masa -->


<!-- Date: Wed Oct 3 21:38:26 2001 -->
Results from the tests with L2 cutting on SVT tracks are in the main <a href= 
'/cgi/elog/elog.pl?nb=2001&action=view&page=727&frame=2&anchor=18:43:36'>Shift E-Log</a>.
<!-- Author: Matt -->


<!-- Date: Thu Oct 4 00:02:22 2001 -->
<pre>Tonight, I succeed to put the Reces board in the crate without 
bending pin. My feeling is we had better not to put the board 
which is connected with fibers. So I will disconnect all 
the fibers anytime to put in/pull off the Reces board. 
 
 Anyway, I tested Reces-SMXR connection, and found a bad 
fiber (west phi=0). I suspect the fiber to be disconnected 
at the SMXR side or bad SMXR. I guess no hope to fix it  
untill shutdown. But the other 47 channels are ok, and 
it is sufficient for testing with beam 
 
</pre>
<!-- Author: Masa -->


<!-- Date: Thu Oct 4 14:51:20 2001 -->
The problem with the spare SVTlist board (06) holding BOSS continuously when powered was fixed.  Testing this board with cosmics and SVT sending fake tracks to L2 we now see this board hang the alpha by sending many DSTROBEs within 5 minutes of running with the 10 Hz or so generated by cosmics.  The good SVTlist board (07) has run in this configuration without errors through multiple long runs.  Plots from the LA are below.
<!-- Author: Matt -->


<!-- Date: Thu Oct 4 15:03:33 2001 -->
<center><a href='/elog/notebooks/l2/Thu_Oct__4_2001_150221.ps'><img src='/cgi/elog/det-system-elog.pl?nb=l2&action=view&page=-382' ></a><a href='/elog/notebooks/l2/Thu_Oct__4_2001_150236.ps'><img src='/cgi/elog/det-system-elog.pl?nb=l2&action=view&page=-384' ></a></center>
<!-- Author: Matt -->
<!-- Comment: Thu Oct  4 15;17;44 comment by...Matt -->
<b>Left plot</b>: good event.  <b>Right plot</b>: bad event.  The testpoints are as follows:<p>
<TABLE border> <TR><TH>SVTlist signal</TH><TH>LA pin</TH></TR>
<TR><TD>START_LOAD_CLEAN</TD><TD>0</TH></TR>
<TR><TD>WE_ARE_BOSS</TD><TD>1</TD></TR>
<TR><TD>S0_OUT</TD><TD>2</TD></TR>
<TR><TD>S1_IN</TD><TD>3</TD></TR>
<TR><TD>S1_OUT</TD><TD>4</TD></TR>
<TR><TD>S2_IN</TD><TD>5</TD></TR>
<TR><TD>S2_OUT</TD><TD>6</TD></TR> <TR><TD>S3_IN</TD><TD>7</TD></TR>
<TR><TD>S3_WAIT</TD><TD>8</TD></TR>
<TR><TD>S3_OUT</TD><TD>9</TD></TR> <TR><TD>S4_IN</TD><TD>10</TD></TR>
<TR><TD>S4_OUT</TD><TD>11</TD></TR> <TR><TD>DDONE</TD><TD>12</TD></TR>
<TR><TD>DSTROBE</TD><TD>13</TD></TR> <TR><TD>EE_FIFO_MB</TD><TD>14</TD></TR>
<TR><TD>BUFFER_MATCH</TD><TD>15</TD></TR> <TR><TD>LOCAL_REQ</TD><TD>16</TD></TR>
<TR><TD>SM_RESET</TD><TD>17</TD></TR>
<TR><TD>empty</TD><TD>18</TD></TR>
<TR><TD>empty</TD><TD>19</TD></TR>
</TABLE BORDER><p>

<!-- Date: Thu Oct 4 17:02:16 2001 -->
<pre>
SVT rebooted this afternoon to fetch latest changes in svtvme
& svtmon:
- corrected generation of SSmap should give us back half of wedge 0
- protection added not to update beam correction lookup table
  in GB if the fit for a given barrel not yet available
</pre>
<!-- Author: Marco -->



<!-- Date: Thu Oct 4 19:42:04 2001 -->
Arnd and I spent some time getting the handshake between the error handling and run control working. After fixing a bunch of bugs in my code, we can now get the run control to print a mesage in the merlin window when it detects an error. 
 
<p>Currently running monitors are: 
<ul> 
<li>L1Mon (only one word/event)</li> 
<li>ClistMon sync check</li> 
</ul> 
The SVT-XTRP BC check is disabled.
<!-- Author: Peter Wittich -->


<!-- Date: Fri Oct 5 23:56:44 2001 -->
Results from L2 cutting on SVT<p> 
<b>128419</b>: TEST_TWO_TRACK_SVT[5,205] with L2exe TEST_TWO_TRACK_SVT_v-5_svtbeamnoerror_B0L2PR00 (SVTlist/tracklist bc mismatch check disabled).  Alpha tagging, L1A = L2A = L3A = 65 Hz.  Deadtime < 0.01% with the following trigger setup (only L2 triggers with non-zero L1 triggers feeding them are listed):<p><TABLE border> 
<TR><TH>L1 Trigger</TH><TH>prescale</TH><TH>rate (Hz)</TH></TR> 
<TR><TD>1</TD><TD>0</TD><TD>0</TD></TR> 
<TR><TD>3</TD><TD>0</TD><TD>0</TD></TR> 
<TR><TD>5</TD><TD>10</TD><TD>12</TD></TR> 
<TR><TD>7</TD><TD>0</TD><TD>0</TD></TR> 
<TR><TD>9</TD><TD>200</TD><TD>12</TD></TR> 
<TR><TD>11</TD><TD>250</TD><TD>35</TD></TR> 
<TR><TD>21</TD><TD>50k</TD><TD>6</TD></TR> 
<TR><TD>23</TD><TD>10M</TD><TD>1.7</TD></TR> 
<TR><TD>53</TD><TD>0</TD><TD>0</TD></TR> 
</TABLE BORDER><p><TABLE border> 
<TR><TH>L2 Trigger</TH><TH>prescale</TH><TH>rate (Hz)</TH></TR> 
<TR><TD>1</TD><TD>1</TD><TD>6</TD></TR> 
<TR><TD>2</TD><TD>1</TD><TD>1.7</TD></TR> 
<TR><TD>6</TD><TD>200</TD><TD>0.2</TD></TR> 
<TR><TD>7</TD><TD>200</TD><TD>0.1</TD></TR> 
<TR><TD>8</TD><TD>5</TD><TD>2.4</TD></TR> 
<TR><TD>10</TD><TD>1</TD><TD>0.4</TD></TR> 
<TR><TD>11</TD><TD>1</TD><TD>0.7</TD></TR> 
<TR><TD>12</TD><TD>1</TD><TD>0.2</TD></TR> 
</TABLE BORDER><p> 
All 4 L2 interface boards look good in TrigMon, with both SVTlist and XTRPlist in sync for the entire run.  Took 150k L3A in roughly 40 min of running.<p> 
<b>128423</b>: TEST_TWO_TRACK_SVT[5,205] with L2exe TEST_TWO_TRACK_SVT_v-5_svtbeam_B0L2PR00 (tracklist bc mismatch check enabled).  Alpha cutting, with L1A = 62 Hz, L2A = L3A = 11 Hz.  Individual trigger rates were about the same as those given for run 128419.  Forced to HRR roughly every 1.5 minutes because of L2 timeout from a bc mismatch.  This was always coincident with the sync loss lights coming on in SVT.  Took 7.5k events.<p> 
<b>128424</b>: Physics_0_01[48,213] with L2exe Physics_0_01_v-48_svtcut_B0L2PR00 (bc mismatch check enabled).  Alpha tagging with L1A = L2A = 250 Hz.  Deadtime about 50% (99% of which is BUSY from an overloaded CSL - mostly from a hot wedge in the DIRAC triggers).  All interface boards look good in TrigMon.  Took 100k L3A.<p> 
<b>128425</b>: Physics_0_01[48,213] with L2exe Physics_0_01_v-48_svtcut_B0L2PR00 (bc mismatch check enabled).  Alpha cutting.  We weren't able to run because of nearly instantaneous SVT sync loss in a repeatable pattern:<p> 
20 events: L2 timeout, bc error, SVT sync loss lights on, HRR<br> 
22 events: L2 timeout, L1 sent 0 words error, HRR<br> 
77 events: L2 timeout, bc error, SVT sync loss lights on, HRR<br> 
79 events: L2 timeout, L1 sent 0 words error, HRR<br> 
86 events: L2 timeout, bc error, SVT sync loss lights on, end run<p> 
This is the same frequency and pattern with which the SVT would lose sync when L2 was cutting on jets, as seen previously by Bill and Matt.  This problem was resolved by feeding L2 a fake track pattern from SVT, so this test could be repeated with the fake track pattern generated by Stephen.<p> 
Conclusion: we are able to take data with L2 cutting on SVT tracks at a low rate and a limited set of triggers.  It appears SVX/SVT sync problems cripple these tests with the physics trigger table at a higher rate of data taking, which is consistent with behaviour seen by these systems during the jet cutting tests.  Selected plots from these runs are below.
<!-- Author: Jane and Matt -->


<!-- Date: Sat Oct 6 00:25:14 2001 -->
<center><a href='/cgi/elog/det-system-elog.pl?nb=l2&action=view&page=-385&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=l2&action=view&page=-385' width='300'></a><a href='/cgi/elog/det-system-elog.pl?nb=l2&action=view&page=-386&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=l2&action=view&page=-386' width='300'></a></center>
<!-- Author: Jane and Matt -->
<!-- Comment: Sat Oct  6 00;26;58 comment by...Jane and Matt -->
Left plot: alpha tagging.  Right plot: alpha cutting.


<!-- Date: Sat Oct 6 00:28:27 2001 -->
<center><a href='/cgi/elog/det-system-elog.pl?nb=l2&action=view&page=-387&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=l2&action=view&page=-387' width='300'></a><a href='/cgi/elog/det-system-elog.pl?nb=l2&action=view&page=-388&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=l2&action=view&page=-388' width='300'></a></center>
<!-- Author: Jane and Matt -->
<!-- Comment: Sat Oct  6 00;29;17 comment by...Jane and Matt -->
Left plot: alpha tagging.  Right plot: alpha cutting.


<!-- Date: Sat Oct 6 09:08:21 2001 -->
Disabled hf_w03_b4b5 in default.hwset, in nosvx.hwset, and in hardware database, so that I can pull it out and connect a 
logic analyzer to hf_w03_b2b3.  
<!-- Author: Ashmanskas -->
<!-- Comment: Sat Oct  6 10;55;14 comment by...Bill -->
On second thought, for the meantime, I removed wedge 3
altogether (masked at mrg_tf_0 too) and removed mrg_w03,
because it needs a firmware upgrade to have VME-programmable
DIP switches.