<!-- Title: 14:04:11  Thu Mar 25 2004 -->
<!-- Crewchief: Anyes -->
<!-- Op1: Kevin -->
<!-- Op2: &nbsp; -->
<!-- Op3: &nbsp; -->
<!-- Op4: &nbsp; -->
<!-- Op5: &nbsp; -->
<!-- Op6: &nbsp; -->
<!-- Notes: -->
<pre>Test XTRP 2TT with fractional prescal</pre>


<!-- Date: Thu Mar 25 14:05:51 2004 -->
Replace trig_x.mcs trig_x12.mcs
<!-- Author: Anyes -->


<!-- Date: Thu Mar 25 14:31:38 2004 -->
Power cycle crate<Br> 
Loading daq test XTRP_V2  with physics_02_3<Br> 
Change vme register, x9008_003C  to <br> 
x50 -> 80 which 1/2 160 where bunch counter goes from 0 to 159.<br> 
Run #180857 <br> 
Looks ok, bit 14/15 do change  
<!-- Author: Anyes -->


<!-- Date: Thu Mar 25 14:39:10 2004 -->
Testing changing the vme register when pausing run <br> 
Run # 180861 <br> 
change from x50 to x28 (40dec) at 111 events  <br> 
change x28 to x78 (120dec) at 426 events  <br> 
change x78 to x50  at 687 events <br>  
<!-- Author: Anyes -->


<!-- Date: Thu Mar 25 14:44:27 2004 -->
Run 180862 <br> 
Changing prescale on the fly <br> 
Event prescale <br> 
0    x50 <br> 
493  x28 <br> 
708  x78 <br> 
831  x50 <br> 
953  x78 <br> 
  
<!-- Author: Anyes -->


<!-- Date: Sun Mar 28 18:31:24 2004 -->
<pre>I have replaced the default trig_x.mcs file with trig_x12.mcs for run 181013 to allow 7 track ORing and fractional prescale.  I powercycled the crate and showed shift crew where and how to do this.</pre>
<!-- Author: Christopher -->
<!-- Comment: Sun Mar 28 21;23;41 comment by...KPitts -->
<pre>trig_x12.mcs was in for run 181013.</pre>
<!-- Comment: Sun Mar 28 21;58;42 comment by...KPitts -->
<pre>The 7-track ORing worked correctly.</pre>
<!-- Date: Sun Mar 28 21:23:10 2004 -->
<pre>I switched trig_x.mcs back to the default version (trig_x10.mcs). 
 
I replaced wpipee_x.mcs, wpipeo_x.mcs with the 98x12 versions for the MUON_TEST run which is run #181014.  The ace power cycled the XTRP crate to pick up these changes.</pre>
<!-- Author: KPitts -->



<!-- Date: Sun Mar 28 21:37:46 2004 -->
<pre>I switched back to the default versions (98x11) of wpipee_x.mcs and wpipeo_x.mcs. 
 
Run 181014 showed strange behavior in the low pT CMU bits.  I will check the run offline.  We are reverting back to default XTRP firmware and running the MUON_TEST table again to see if this anomaly is related to the trigger table or the 98x12 firmware.</pre>
<!-- Author: KPitts -->
<!-- Comment: Sun Mar 28 21;58;08 comment by...KPitts -->
<pre>The subsequent run with all XTRP firmware back to default (run = 181015) showed the same strange low pT muon problem.  We suspect the MUON_TEST trigger table.</pre>


<!-- Comment: Sun Mar 28 22;43;26 comment by...KPitts -->
<pre>Track pruning in 98x12 version of the pipes works correctly.</pre>

<!-- Comment: Mon Mar 29 00;11;11 comment by...KPitts -->
<pre>It looks like the CMU high threshold doesn't get loaded properly from the MUON_TEST table.  When we went back to running with the physics table, everything was ok.</pre>


<!-- Date: Mon Mar 29 00:13:09 2004 -->
<pre>Summary of tonight's tests:  success! 
 
We will probably have to switch back between firmware versions in the coming days to keep up with trigger tables.  As of right now, we are back to running with default pipes and 2TT trig_x. 
 
I will give a new version of XTRPSim/XTRPMon to Charles tomorrow so that the monitoring will keep up with these changes.</pre>
<!-- Author: KPitts -->


<!-- Date: Wed Mar 31 11:42:18 2004 -->
Forgot to put an entry here for earler test<br> 
Test this morning PHYSICS_TEST_2_04 [3,452,447], switch to trig_x12.mcs (~9am) <Br> 
Due to some problem with the Si colling, no Si during that test <Br> 
Swap back to trig_x10.mcs.current after test ~10.30am
<!-- Author: Anyes -->


<!-- Date: Wed Mar 31 13:17:58 2004 -->
Changing to trig_x12.mcs for test with PHYSICs_TEST_2_04 with Si this time <Br>
<!-- Author: Anyes -->
<!-- Comment: Wed Mar 31 13;18;39 comment by...anyes -->
Well actually Si is still having problem, so I restored the default as asked. 


<!-- Date: Wed Mar 31 14:21:12 2004 -->
Change yet again firmware to version 12 for testing, CR says they are ready with Si to start test. <BR>
<!-- Author: Anyes -->
<!-- Comment: Wed Mar 31 15;17;02 comment by...Anyes -->
Put it back to verison 10 (default) done with test


<!-- Date: Sun Apr 4 01:10:46 2004 -->
<pre>Copied trig_x12.mcs into trig_x.mcs for trigger table tests.  Runs 181244, 181245, 181246 were taken with this configuration.  Changed back to trig_x10.mcs for subsequent runs.  I checked the data after the testing was completed to verify that the original x10 version was loaded. </pre>
<!-- Author: KPitts -->


<!-- Date: Tue Apr 6 12:10:25 2004 -->
Switch firmware to version 12 at ~10:40 for test with PHYSICS_TEST_2_04[3,455,447] <br> 
Switch back to default at ~12.00 <Br>
<!-- Author: Anyes -->


<!-- Date: Sat Apr 10 15:20:42 2004 -->
<pre>Copied trig_x12.mcs into trig_x.mcs, had ace power cycle the crate.  This is (hopefully) one of the last times we have to do this.  Run was 181477 (plus a few other aborted attempts.)  Changed back to trig_x10.mcs for subsequent run, ace power cycled the crate.</pre>
<!-- Author: KPitts -->
<!-- Comment: Sat Apr 10 15;21;08 comment by... KPitts -->
<pre>I verified offline with the next run (181480) that the trig_x.mcs firmware was put back properly.</pre>


<!-- Date: Sat Apr 17 11:50:04 2004 -->
<pre>XTRP Firmware changed (hopefully for good!) 
 
New defaults: 
  wpipee_98x12.mcs 
  wpipeo_98x12.mcs 
  trig_x12.mcs 
 
It will only be necessary to change back if we revert back 
to a physics_2_03 trigger table.</pre>
<!-- Author: KPItts -->


<!-- Date: Fri May 21 11:25:13 2004 -->
<pre>Clock board should only be exchanged from READY state</pre>
<!-- Author: Christopher -->


<!-- Date: Fri May 21 12:41:55 2004 -->
L2 torture run 182925 looked normal on XTRPMon.<Br> 
Took a Cosmic Run but got not tracks  182925 <BR> 
Going back to L2 torture run 182928.<Br> Don't see any errros anymore.
<!-- Author: Anyes -->
<!-- Comment: Thu Jun 24 16;01;37 comment by...James Kraus -->
<pre>I looked at run 182898 offline.  It looks like there were no bits set by board 11 for the muon triggers, but some bits in boards 0 and 10 were set high.  Also, the bits in two-track trigger were almost all set higher than the sim indicated, but not at the bunch crossing rate.  Cal bits 0,1, and 3 were set high for wedges 0, 22, and 23, but bit 2 looked normal.</pre>
<!-- Date: Fri May 21 13:09:15 2004 -->
Cosmic table with fake track can't take the rate (huge dead time).<Br> 
Use Physics table  (no Silicon) & load fake track, still 90% dead time, but get enought to tell that the errors are gone.(run 182930).
<!-- Author: Anyes -->


<!-- Date: Fri May 21 14:42:45 2004 -->
<pre>Testing the fractional prescal firmware trig_x14.mcs (current version is 12).&lt;Br&gt; 
Using Physics table 2_05. &lt;Br&gt; 
Using teststand14 (mike's area), File-&gt; edit config, import crate, b0xtrp02.crate, open connection (don't so init system give error on 2TT) &lt;Br&gt; 
Run 182937 &lt;Br&gt; (pausing to do changes) 
About 360 evts write in x9008_003C (A32:D32) x80(128dec) read back ffff0f80 &lt;BR&gt; 
About 550 evts write in x9008_003C (A32:D32) x40(64dec) read back ffff0640&lt;BR&gt; 
About 735 evts write in x9008_003C (A32:D32) xC0(192dec) read back ffff06C0 &lt;Br&gt; 
 
</pre>
<!-- Author: Anyes -->


<!-- Date: Fri May 21 14:51:01 2004 -->
<pre>Restore trig_12x.mcs&lt;BR&gt; 
Taking a test run with physics table 2_05 to check that everything is back to normal. 182949.</pre>
<!-- Author: Anyes -->


<!-- Date: Fri May 28 09:45:26 2004 -->
<pre>Testing of Spare Cards: 
183349 Control Run 
183351 Replace Data board in Slot 16 with DB3-022 
183353 Return original Data board in slot 16, and 
       Replace clock board with CC-003  
183354 Rerun with original boards</pre>
<!-- Author: Christopher -->


<!-- Date: Fri May 28 11:40:27 2004 -->
2TT test with physics table physics_test_2_05_v3 <BR> 
1000 evts test, trig_x14.mcs in <Br> 
Run 183371:<BR> 
<li> 102 evts read 0, write xFA (250dec) reading back 0cfa <Br> 
<li> 280 evts, writing x64 (100dec) 
<li> 421 evts, read x64, write x32(50dec) 
<li> 744 evts, read x32, write xFF(255dec)  
<!-- Author: Anyes -->


<!-- Date: Fri May 28 11:42:25 2004 -->
<pre>3TT/transverse maps Testing with base=11: 
183357 simA_c, old mt_map 
183365 simB, old mt_map 
183367 simB, new mt_map 
183369 simA_c, new mt_map</pre>
<!-- Author: cmarino -->


<!-- Date: Fri May 28 12:05:55 2004 -->
2TT 10000k test, run 183374 <Br> 
<li> 2522 read 0 wrote xFF 
<li> 4705 read xFF, wrote 7A 
<li> 6829 read 7A, wrote x25 
<li> 8940 read x25, wrote 1 <BR> 
  
<!-- Author: Anyes -->


<!-- Date: Fri May 28 12:22:46 2004 -->
Testing  Bill W code Run 183376 <Br>  
Still using the physics table:physics_test_2_05_v3 <Br> 
setup fer <BR> 
java rc.vxmon.PrescaleChanges 2 1 <BR> 
(where 2 is the partitionId and 1 is the trigger level) <BR> 
This will send a message to xtrp to change the FPS to 123 <BR><BR> 
 
<li> Pausing 717.... reading 0<Br> 
Executing Bill code: <BR> 
Attempting connection to <tcp:b0dap33:5101> RTserver. <BR> 
Connected to <tcp:b0dap33:5101> RTserver.<BR> 
*** PrescaleChanges.main timed out waiting for reply ***<BR> 
Reading back 0 !... does not work ??? <BR> 
<li> Putting back in Active<Br> 
Excecuting Bill code <Br> 
Attempting connection to <tcp:b0dap33:5101> RTserver.<BR> 
Connected to <tcp:b0dap33:5101> RTserver.<BR> 
*** PrescaleChanges.main timed out waiting for reply ***<BR> 
Pausing... Reading back 0! <BR> 
Either we are misusing this... or it does not work... 
 
 
 
 
  
<!-- Author: Anyes -->


<!-- Date: Fri Jun 4 14:35:28 2004 -->
<pre>3TT testing 
 
183645 Control 2TT run 
all following runs gave 0 for ttword 
183650 simtracks_mt.dat, mt_maps.dat.new, and tr_e6.mcs 
183654 reload firmware without changing clock to vme 
183660 same as 183654 but with tr_e7.mcs 
183665 same as 183660 but with mt_maps.dat.backup 
183668 final attempt -- powercycled crate, reloaded everything  changing clock to vme, used: mt_maps.dat.backup, tr_e7.mcs 
</pre>
<!-- Author: Christopher -->


<!-- Date: Fri Jun 4 15:32:50 2004 -->
2TT test with fractional prescal (Bill code)<BR> 
run 183678 (physics_test_2_05_v3), track file cmarino <Br> 
setup fer v3_38<BR> 
e.g java rc.vxmon.PrescaleChanges 5 0 10 (5 partition, 0 trigger level, 10 what gets written to XTRP)<BR> 
<li> pause evt 165 read 0 write 10 read xA  
<li> pause evt 402 read xA write 122 read 7A 
<li> pause evt 724 write 37 read x25  
Look like Bill code works<Br> 
Here an example of what ones get running the test <Br> 
java rc.vxmon.PrescaleChanges 5 0 37<Br> 
Attempting connection to <tcp:b0dap33:5101> RTserver.<Br> 
Connected to <tcp:b0dap33:5101> RTserver.<BR>  
<!-- Author: Anyes -->


<!-- Date: Mon Jun 14 16:30:31 2004 -->
<pre>Summary of 3TT firmware testing: 
 
Changed startup code, used base=2, swapped boards, configured with xtrp daq test v2 and used full 3tt prep for data flow button on status panel in READY state 
 
183997 phi binning lookup fpgas and maps, using simtracks_mt.dat 
   saw ttword 15/16 were 0 
183999 use simtracks_marino.dat 
184000 attempt to pause run a read out buffers, discover that          
   wtrack file has not been changed and Init system not marked 
Reboot crate and test for Init system affects 
184002 run with wtrack3_x4.mcs, but no Init system 
184003 run with wtrack3_x4.mcs and Init system 
   paused this run in several places to check for track passing</pre>
<!-- Author: Christopher -->


<!-- Date: Fri Jun 18 13:03:58 2004 -->
<pre>Summary of XTRP - 3tt testing (morning of June 17) 
 
184089 3tt test using simtracks_marino, wtracks3_x4.mcs(verified  
       version 7 with vme block read), base=2, L2_torture table 
       --get some agreement and some reasonable errors 
184093 change to simtracks_mt (only 2/16 event show errors) 
184096 change to base=11 for 3tt data word readout (successful) 
184097 pause run and check with vme block read 
184100/2 returning to simtracks_marino, adjusting interval 0 
184106 physics table used 
returned base to 2, startup code to default, and wtracks_x.mcs.2tt 
 
Offline analysis shows 9/16 events in simtracks_marino are correct.  Trouble with tracks being dropped or passed incorrectly appears to account for most differences.  New simtracks files designed to systematically search for this.</pre>
<!-- Author: Christopher -->



<!-- Date: Tue Jun 29 13:25:07 2004 -->
3TT -003 testing: 
<li>board 001 determined to have a short in wedges 7 and 8<br> 
<li>verifying that 003 behaves similarly to 001 with the exception of no wedge 7/8 errors<br> 
<li>L2 torture table, base 11, changed startup code and wtracks ... 
<br> 
<br>184544 - simtracks_marino 
<br>184545 - simtracks_beamerrorD 
<br>184546 - simtracks_mt 
<br>184549 - simtracks_test1_mt
<!-- Author: Christopher -->
<!-- Comment: Thu Jul  1 15;27;18 comment by...Christopher -->
later this evening I ran identical tests on 3TT-001 which had been fixed from its short.  These were runs: 184575, 184577, 184582, and 184584.<br>

<br><li> Additionally I ran a L2 torture with a rat 100x as high for 20k events with simF


<!-- Date: Fri Jul 23 09:17:36 2004 -->
XTRP test for wedge 10, board 5 slot 11, segment 123 missing. <BR> 
Using SIMTracks/simtracks_w10.dat <BR> 
Run #185439 <BR>  
<!-- Author: Anyes -->
<!-- Comment: Fri Jul 23 09;40;46 comment by...anyes -->
Get some error on wedge 10 as seen during data taking


<!-- Date: Fri Jul 23 09:41:45 2004 -->
Replaced databoard in slot 11 with DB3-022. <BR> 
#run 185443
<!-- Author: anyes -->
<!-- Comment: Fri Jul 23 10;37;05 comment by...anyes -->
Chris monitoring plots still shows errors, however, Kevin saw that the sim bit are all 0 (pb with tcl?). <BR>
(I rerun with my tcl and it looks fine apart for the bunch Xsing erros and the crack bits) <BR>
Look that this data board as a crack bit not working, ok don't use them  (try the other one? well looks even more dodgy) <Br>
Also the 2TT saws lot of bunch Xsing errors <Br>
Taking another run after power cycling crate run 185446 <Br>
I still see lots of bunch crossing errors.



<!-- Date: Fri Jul 23 10:49:43 2004 -->
Replace DB3-022 with DB2-010 in case that works better in term of bunch Xsing & many crack bit. Hopefully doesn't have anoter problem. <Br> 
Run 185447 with DB2-010. <BR>  
<!-- Author: anyes -->


<!-- Date: Fri Jul 23 11:12:57 2004 -->
<pre> XTRPSimModule::getFromD applying conditions from run 185447 to simulated data! 
%ERLOG-e Error fetching TrgSimRows, return code : 
         /cdf/home/cmarino/cdf2/Monitoring/XTRPSim/src/XTRPSimModule.cc : 1810 
         DataNotFound  XTRPSim XTRPSimModule::getFromDB() 
         23-Jul-2004 10:51:22 CST run = 185447 event = 0 
 
Errors from Monitoring code were due to failure to retrieve offline database.</pre>
<!-- Author: Christopher -->


<!-- Date: Fri Jul 23 11:22:46 2004 -->
<Li> DB3-022 will go down to UIUC to look into the trigger error & also  
the crash bit error. <BR> 
<li> The original DB3-019 that shows error during data taking will go down next, once we have DB3-022 back. <BR> 
The one may need a ram replaced. Keep it as spare in the mean time since it only a problem in 1 segment. <BR> 
<li> Current data board in slot 11 is DB2-010 and working ok.<BR> 
In the process of testing DB2-010, we reproduce the DB error seen online. <BR>   
<!-- Author: Anyes -->


<!-- Date: Fri Jul 23 11:35:56 2004 -->
Onto 3TT cold start testing. <Br> 
<li> Using physics table 2_05_v11 with simtracks. <Br>  
Act like the L1_SEVEN threshold is the L1_TEN threshold and then we 
should be able to check the data using trigmon.<Br> 
<li> Replace in start.xtrp FER_SmartTrig with FER_SmartTrig.3TT_new<Br>
<!-- Author: anyes -->


<!-- Date: Fri Jul 23 15:41:27 2004 -->
Got ime out error after 1 event, trying HRR. <BR> 
Looks like the FPGA are not getting sets (at least the trigger one) 
<Br> I can't yet see where in the code it is going wrong.<BR> 
This did not change from my previous version of 3TT code.
<!-- Author: Anyes -->


<!-- Date: Thu Jul 29 13:40:36 2004 -->
<pre>WEDGE 12 TEST: 
 
runs with DB3-021 in slot 12 (default) 
185651 simtracks_marino 
185658 simtracks_tt12test 
185657 simtracks_tt12test2 
all these show wedge 12 errors 
 
runs with DB3-019 in slot 12 (spare) 
185653 simtracks_marino 
185655 simtracks_tt12test 
185656 simtracks_tt12test2 
do not show any errors!!!</pre>
<!-- Author: Christopher -->


<!-- Date: Sat Jul 31 19:53:33 2004 -->
<pre>RC code testing: 
I could not get 3TT-001 to load using the new rc code, the old rc code or even by hand.  Just got bus errors. 
So, I switched to 3TT-003 and loaded by hand, using Physics Table 2_05 v11.  This more or less worked.  2 events showed some trigger word errors that I cannot immeadiately account for. 
Anyes new rc code gave the following output right before hanging. 
 
CodeRam3TTLoad: loading to code Ram 7 file /cdf/code-common/cdfonline/xtrp/wc3.txt 
CodeRam3TTLoad: Done loading code Rams 
Loading Three Track RAMs (pt only)... 
        Failed to open trigger_maps_debug.dat 
TrigRam3TTLoad: parallel write to pt Rams 
TrigRam3TTLoad: reading back pt Rams one at a time 
TrigRam3TTLoad: Done with pt Rams 
</pre>
<!-- Author: Christopher -->


<!-- Date: Sun Aug 1 12:47:01 2004 -->
<pre>Testing RC code for 3TT &lt;Br&gt; 
&lt;li&gt; run 185814: using mt_maps.dat 
Still can write the debug file with maps.  
I tried the vxworks directory and also just nothing. 
 
&lt;li&gt; run 185814: using the physics table 
Hungs after loading the pt rams. My guess is that the code write 
outside the array, Let's dump it, since I can't get the output file. 
 
&lt;li&gt; run 185819: last address is 4001f which is beyond max @ 40000 . I also see that bit is always 0, but did not check all the add. 
See dump XTRP3TT/test/run3TT_185819.log  
 
 
</pre>
<!-- Author: Anyes -->


<!-- Date: Mon Aug 2 08:51:00 2004 -->
Testing 3TT Rc <Br> 
<li> Run 185838 3TT & physics table 2_05_11.  
<li> Run 185839 3TT & physics table 2_05_11. 
<li> Run 185840 2TT & physics table 2_05_11 using dual 2TT/3TT RC code 
<li> Run 185841 2TT & physics table 2_05_11 with standard FER code. However I forgot to put back extra 5 to 0, so rubbish. 
<li> Run 185842: Re-2TT: looks OK. 
<Br> 
When trying to look at run offline, we always have trouble getting the DB. Usually, it works on the second try, this morning that's not always the case. 
<Br>
<!-- Author: Anyes -->


<!-- Date: Mon Aug 2 09:16:34 2004 -->
Some problem with extra5=1 on the previous runs. 
<Li> Run 185843: 3TT again. Using extra5 for the debug seems to interact somewhere else in RC code and not loading L2 tagset/physics table. Retook run without this. Looking offline at the sim, we have trigger word errors. 
<li> Run 185844: 2TT using my RC code without the extra5=1. Sim looks good, so at least I did not break anything<BR>
<!-- Author: Anyes -->


<!-- Date: Tue Aug 3 15:30:17 2004 -->
XTRP Board testing<br> 
-removed DB3-021 with wedge 12 errors (is now backup DB) <br> 
-found DB3-022 to have IMU and crack bit errors (back to Urbana) <br> 
-board DB3-028 works well and is now in slot 12<br> 
-board DB3-019 (segment 123 error) down to Urbana<br> 
-3TT-001 still gives bus errors and nonsense trigger words<br>  
<!-- Author: Christopher -->


<!-- Date: Sat Aug 7 10:30:50 2004 -->
Testing 3TT beam test <BR> 
<li> Run 186044: physics_test_2.05(27,522,482), enable extraDBanks. No Silicon. <BR> 
Debug file in /mnt/autofs/cdf/code-common/cdfonline/xtrp3TT/trigger_maps_debug_186044.dat<BR> 
 
<li> Looks like we have fractional prescale in that trigger table. Not in 3TT. <BR> 
+++ PrescaleChanges 0 0 <BR> 
XTRP_setFractionalPrescale(255,0) success; event 17500 <BR> 
I don't think that work tho looking at daqmon.<BR> 
 
See some trigger error in XTRPMon, especially bit 8. Got wedge 10? error as usual<BR> 
 
<li> looking at the debug file, I see some 0 and some large number (1278, 1274, 1268) I not so sure what to expect there. <BR> 
 
<li> Ace had forgotten to make sure the files endup to sgi. Starting again. 
 
 
 
  
<!-- Author: anyes -->
<!-- Comment: Sat Aug  7 11;04;32 comment by...Anyes -->
Actually we got the files onto the look area.

<!-- Date: Sat Aug 7 10:45:41 2004 -->
<li> Run 186045: same setting apart for, in principle getting the file to the look area & tape. However, still don't get anything.<Br> 
Waiting that a stream get written out 
  
<!-- Author: anyes -->
<!-- Comment: Sat Aug  7 11;01;00 comment by...Anyes -->
File coming to the look area. Should also be written to tape.
<!-- Comment: Sat Aug  7 11;14;45 comment by...Anyes -->
Check offline using stream D that got the banks. All look ok, well
see same type of error than online
<!-- Date: Sat Aug 7 10:48:28 2004 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=xtrp&action=view&page=-4&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=xtrp&action=view&page=-5  width='300' align='top'></a></td><td>Just for fun... prescale Fred... got L1_TEN</td></tr></table>
<!-- Author: anyes -->



<!-- Date: Sat Aug 7 11:03:55 2004 -->
<li> Run 185046, using physics_2_05 [11,508,479]. Just in case there were problem with the other table.
<!-- Author: Anyes -->




<!-- Date: Sat Aug 7 11:20:49 2004 -->
Resume: 
<li> Run 186044, physics_test_2.05(27,522,482), enable extraDBanks<br> 
Forgot to enable writting files to look area/tape. <Br> 
Files did show up there anyway. 
<li> Run 186045, physics_test_2.05(27,522,482). Enable writting file to look area/tape. 
<li> Run 186046, physics_2.05 (11,508,479)  
<li> Put back 2TT but left in the fer code (since it works the same)  
<!-- Author: Anyes -->


<!-- Date: Tue Sep 21 11:56:39 2004 -->
3TT testing - attempt to replicate beam test errors <br> 
<br>187375 2TT - control run PHYSICS_2_05 [11,508,479] 
<br>187377 3TT - control run PHYSICS_2_05 [11,508,479] 
<br>187380 3TT - test with simtracks_brd5_errors.dat  
<br>187381 3TT - repeat of simtracks_brd5_errors.dat with v27 table 
<br>187382 3TT - test with simtracks_NO5_errors.dat PHYSICS_TEST_2_05 [27,522,482] 
<br>187383 2TT returned<BR><BR> 
No 3TT errors produced!!
<!-- Author: christopher -->
<!-- Comment: Tue Sep 21 11;57;02 comment by...christopher -->
<pre>using 3TT-003</pre>

<!-- Comment: Tue Oct  5 17;34;35 comment by...Christopher -->
<pre>Repeated all these tests in runs 187755 - 187774 Monday Day shift, Oct. 4.  Still was not able to reproduce errors.  Could not do Base 11 readout with normal startup up code.  Still took simtracks_final_errors.dat run with 187768.  Mixed results.  Will try again.
</pre>


<!-- Date: Fri Oct 8 16:26:52 2004 -->
<pre>3TT Testing: 
Run 187923 PHYSICS_TEST_2_05 [27,522,482] 
XTRP - 3TT - Myron Mode, simtracks - final errors- 10k 
Run 187926 
XTRP - 3TT - simtracks = 5plus, Myron Mode 10k 
Run 187927 
XTRP - 3TT - test bit 8 
 
The above runs are of some value and demonstrated: that base 11 can not be used with current startup code, that bit 8 is fixed, that board 5 is still not reproducible, and we can reproduce and study residual errors. I was able to get base 11 readout by hand in later runs; however, we need this to work in startup code and it loads different maps.</pre>
<!-- Author: Christopher -->


<!-- Date: Fri Oct 22 15:59:35 2004 -->
<pre>XTRP Work Summary of the last week or so: 
 
Thursday (10/14) - base 11 testing unsuccessful, even by hand  
                   188111, 188115, 188122, 188125 
 
Friday (10/15) - able to confirm base 11 readout problem is not in XTRP.c, but some change in the readout code is causing done timeout. 
               - test all three 3track boards: 
3TT-003 - 188186 
3TT-001 - 188188, 188190, 188191 
3TT-002 - 188195  
 
Runs 188191 and 188195 using simtracks with LL (low level) errors 
3TT-002 does not show these errors! 
 
Tuesday (10/19) - more work on base 11 with Jane 
     - attempt data board testing in parallel with smxr L2T tests 
 
Thursday (10/21) - give up on parallel testing  
 
Run 188337 PHYSICS_2_05 [11,508,479] XTRP - 2TT - DB3-022 in slot    10 (replacing DBII-003) 
Run 188338 PHYSICS_2_05 [11,508,479] XTRP - 2TT - DB3-019 in slot 11 (replacing DBII-010 which has intermittent dirac/3tt errors) 
Run 188339 APHYSICS_2_05 [11,508,479] XTRP - 2TT - DB3-021 in slot 13 (replacing DB3-026) 
Run 188340 PHYSICS_2_05 [11,508,479] XTRP - 2TT - 10k Myron mode test with default simtracks of 3 swapped boards 
Run 188342 PHYSICS_TEST_2_05 [27,522,482] XTRP - 3TT - simtracks_max  
Run 188343 PHYSICS_TEST_2_05 [27,522,482] XTRP - 3TT-003 - simtracks_marino 
 
Run 188346 PHYSICS_TEST_2_05 [27,522,482] XTRP - 3TT-003 - DB3-026 back in slot 13 (DB3-021 out, becomes spare), simtracks_newerrors 
DBII-003 also becomes spare card, DB3-022 left in slot 10 and DB3-019 left in slot 11 
 
Verified no low level errors with board 002. 
Run 188347 PHYSICS_TEST_2_05 [27,522,482] XTRP - 3TT-002 - same config as 188346 but using 002 with 003's prom 
  
Friday(10/22) - 188401(3TT-003), 188405(3TT-002), 188409(3TT-001) -  Tried to use a new simtracks made from errors with the beam test that used fixed maps.  I was not able to reproduce these errors for any board - due to different triggers?</pre>
<!-- Author: Christopher -->


<!-- Date: Thu Nov 4 13:56:29 2004 -->
<pre>3TT STATUS 
 
3TT-002 now has a working prom and works with base 26.  It still shows no low level errors even at dataword level. 
3TT-001 has gone back to Urbana (no base&gt;2 readout), has LL errors 
 
3TT-003 working and working prom, LL errors spotted and verified in data word base 26 readout. 
 
3TT-002 currently in XTRP crate - just to try it out and hopefully take cosmics with cosmic_3Track next week 
 
</pre>
<!-- Author: Christopher -->


<!-- Date: Thu Nov 4 13:58:42 2004 -->
<table border=0><td><tr><td bgcolor=#e0e030>3TT-002 does not fit well into crate. <br>We must make sure it snaps in properly when swapping it as its hinges are loose.</td></tr></td></table>
<!-- Author: Christopher -->


<!-- Date: Wed Dec 15 12:33:03 2004 -->
<li>I've replaced DB3-021 in slot 15 with DBII-003. 
<li>I put the new version of tr_e4.mcs into tr_x.mcs and tested with it.  
<li>I tested the capacitor modified 3TT-001 board, but it did not load properly.  The VME interface light does not come on nor does the V33(top) power light. 
<li>Output files from the DataIMU library are found in /cdf/people2/vxworks/xtrp/IMU_output 
<li>PhiGapNew has become the default DataB library and it puts output files in /cdf/people2/vxworks/xtrp/  
<!-- Author: Christopher -->


<!-- Date: Wed Mar 30 13:54:22 2005 -->
XTRP loading sequence summary:<Br> 
(The time estimate may no be that accurate...)<br> 
After power cycle, crate takes 77sec to configure (run 195914) 
<li> 22 sec that I don't know where it's used. May be accessing/reading the run control config (will check another time) 
<li> 26 sec to load FPGA, coderam, ptram 
<li> 29 sec to load DB 
<Br> 
Once the crate has been configured once, this is what one would gain when: 
<li> not changing the trigger table 27 sec (195915) 
<li> changing the trigger table 17 sec (195916) 
<br> 
I have not yet put in the optimised library. would like to check offline the runs above<BR> 
I left in tr_e3.mcs instead of tr_e4.mcs as default for tr_x.mcs. 
This should not affect anything with the current FER lib.<BR> 
I may still be able to gain a little time from those mistery 20s at the begining.<BR> 
 
  
<!-- Author: anyes -->
<!-- Comment: Wed Mar 30 14;23;34 comment by...anyes -->
NB: If the crate is rebooted, the addresses used for checking if the FPGA or the ptram have already been loaded are not reseted. <BR>



<!-- Date: Mon Apr 18 14:30:50 2005 -->
XTRP databoard slot 5 errors.<BR> 
see:  
<a href= 
'http://www-cdfonlineXTRP DB repair.fnal.gov/cgi-bin/elog.pl?nb=2005&action=view&page=321&frame=2&anchor=20:12:54.417'> 
user link text </a> <BR> 
Located error coming from seg 123 <BR> 
Take run 196720 with simtrack file with track in 123. Don't see any errors.<Br> 
Run 196723: modify slightly the simtrack putting tracks in adjacent wedges. Still can't see errors <Br> 
Since we cannot reproduce the error, we are not swapping the DB.  
<!-- Author: anyes -->


<!-- Date: Tue Apr 26 23:09:59 2005 -->
<b> TESTING OF NEW Mt CODE </b> <BR> <br> 
 
<li> Load new library FER_SmartTrig.3tt_TM_phi0 <br> 
This has harcoded loading Lookups: lv[x]_d8.mcs; [x]=0,1,2,3 & 
tr_e2.mcs, hence no need to change any of the default files. 
<li> Have a simtrack file ready with:<br> 
   low pT (2 GeV) tracks and <br> 
   some cases where there are tracks in adjacent segments (to test the new feature of killing adjacent segments). 
<br><br> 
 
Procedure <br> 
<li> After rebooting the crate when doing config<br> 
Lookup for the following statements <Br> 
Setting FPGA_LUx to 1 to use phi0 <br> 
and the following ones that should shows that 4 addresses are set to 1. 
<li> Write out a set of maps using the TEST_MT_v1 table. <br> 
Maps will be located in: <br> 
/cdf/code-common/cdfonline/xtrp3TT/trigger_maps_debug_mt_phi0.dat<Br> 
You will need  to make a backup of it. (They get overwritten each time the trigger tables changes/crate power cycled). 
<li> Take a run. 
 
 
 
<br>
<!-- Author: Anyes -->


<!-- Date: Wed Apr 27 12:48:27 2005 -->
<pre>Several problem with MT tests: &lt;br&gt; 
&lt;li&gt;oc and ic fpgas not being cleared for reloading after power cycle 
&lt;li&gt;not writing out trig map file due to permissions 
&lt;li&gt;fision error when setting magic registers</pre>
<!-- Author: Christopher -->
<!-- Comment: Wed Apr 27 12;57;34 comment by...Christopher -->
Anyes moves writing of new registers to end of loading sequence in XTRP.c<br>
Trying to change output of map file to code-common area
<!-- Comment: Wed Apr 27 13;24;21 comment by...C -->
<pre>These problems were corrected and run 197038 was taken.</pre>
<!-- Date: Wed Apr 27 12:52:06 2005 -->
<pre>Several problem with MT tests: &lt;br&gt; 
&lt;li&gt;oc and ic fpgas not being cleared for reloading after power cycle 
&lt;li&gt;not writing out trig map file due to permissions 
&lt;li&gt;fision error when setting magic registers</pre>
<!-- Author: Christopher -->
<!-- Comment: Wed Apr 27 13;44;01 comment by...Anyes -->
<br>The problem of permission for witting the maps was fix by Bill <BR>
Both IC/OC loading & fision error that came when doing <Br>
3TT: Reading magic registers <BR>
got away by moving setting the registers to pickup phi0 for the lookup at the end of the loading sequence. <Br>
Are we sure that those registers where not used by anything before ?<br>
I guess I would like to understand why the order matters ? <br>
<br>
The more worrisome part comes when booting up the crate I am getting some errors that I don't recall seing before. <br>
This is the same after putting everything back together.<BR>
Will have to get someone looking into this, I suppect it may be linked to all of what they did this morning. <BR>
Once we look at a run, we'll be able to tell if those matters.


<!-- Date: Thu May 5 12:04:20 2005 -->
<pre>Testing the transverse mass firmware/startup code: 
Previous test resulted in 1 error - tested old code with simtracks designed to track down error. 
197500 - Old TM library - simtracks error 
197502 - Old TM library - simtracks separation 
197507 - New TM library - simtracks separation 
197510 - New TM library - simtracks error</pre>
<!-- Author: Christopher -->


<!-- Date: Tue Jun 7 12:10:27 2005 -->
<pre>Test Runs from Friday June 3: 
 
198925  Test_MT table with phi0c library simtracks_MT_dphi 
198926  Test_MT table with phi0c library simtracks_MT_error 
198927  Test_MT table with phi0c library simtracks_LL_errors 
 
These tests showed the new firmware (lvX_d6.mcs) eliminated the problems with crossed phi-ordering in the phi6-&gt;phi0 translation and adjacent linker handling. 
 
198929 changed to base=26 and lvX_d5.mcs firmware, Physics table 
This firmware changed the timing for track passing.  It checks out (no crashes or new errors), but shows no Low Level error improvement. 
 
Control Runs: 198924(sim_MT_dphi), 198930(sim_LL), and 198931 (sim_MT_dphi) --  all check out normal 
 
Ready to move on to beam test of MT improvements. 
</pre>
<!-- Author: Christopher -->


<!-- Date: Tue Jun 7 12:19:08 2005 -->
<pre>BEAM TEST  - Sunday Eve June 5 
 
Side Note:  Segment 123 error has returned -- need to replace DB-019 in slot 11 with spare DB-027. 
 
Beam Runs 199026(base=2) and 199027(base=26) with AAA_NOSILICON Trigger: TEST_MT [2,657,540] yield good sample of transverse mass events. 
 
Data Analysis quickly reveals a firmware problem crossing 2pi in the phi6-&gt;phi0 translation.  Throwing out events in the first or last 5 segments and segment 123(see note above) to account for known/fixable errors results in 11 Low Level(data word bit dropping) errors and no other errors in 83k events. 
</pre>
<!-- Author: Christopher -->


<!-- Date: Wed Jun 8 10:10:42 2005 -->
<pre>Data Board Testing: 
 
199081 Control Run using DB-019 in slot 11 with simtracks_card5 
          Reseated DB in slot 6 
199083 DB-021 in slot 11, base = 2 
199084 DB-021 in slot 11, base = 26 
199091 DB-027 in slot 11, base = 26 
199101 Control check with DB-027 and base = 2 
 
Difficulty with TrigSim loading, forced manual loading from old run 
 
DB-019 shows 123 errors.  DB-021 shows "wedge 12" errors: exact segments to be determined.  DB-027 shows no errors.  Urbana DB should come up, DB-021 should go down for repair, and DB-019 should have RAM replaced after DB-021 returns.</pre>
<!-- Author: Christopher -->
<!-- Comment: Mon Jun 13 10;13;07 comment by...Christopher -->
<pre>Segments 8,9,and 10 appear to be the problem segments (perhaps 11 too) for the "wedge 12" errors.  These were problems seen only in 3tt not 2tt, and in the July 04 beam test had an error rate of about 350/200k.  The track passed to the 3tt is minus four segments due to bit 10 in the track word being dropped.</pre>
<!-- Date: Sun Jun 12 14:33:26 2005 -->
Wedge 13 errors <BR> 
 
<li>Run 199241 to reproduce error. Booked muonlinker, no idea what I should include to get the dirac. From monitoring plot I see errors in wedges 12-13-14, but not in the dirac. 
<li> Run 199247, this time I book L1 & L2 cal just in case. Same thing.  
<li> Run 199248, Power cycle crate & removed the L1/L2 cal crate. Still see the same errors. 
<Br> 
Replace DB28 in slot 12 with DB10. Doing this I notice that the lead on the next board (slot13) are a bit dodgy (pipe 6 & 7) <Br> 
Cross finger that I have not make any pin error (gosh all the board move when one pull one out). 
 
  
<!-- Author: anyes -->


<!-- Date: Sun Jun 12 14:34:31 2005 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=xtrp&action=view&page=-6&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=xtrp&action=view&page=-6  width='300' align='top'></a></td><td>This is how the monitoring plot looks like for runs 199241,199247,199250.</td></tr></table>
<!-- Author: anyes -->


<!-- Date: Sun Jun 12 14:42:28 2005 -->
Run 199249: after replacing DB28 slot 12 with DB10. <BR> 
Looks like the error in wedge 12-13-14 are almost gone (see plot below). I included the XFT linker crate... most likely I have some pin error in that DB.
<!-- Author: anyes -->


<!-- Date: Sun Jun 12 14:42:55 2005 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=xtrp&action=view&page=-7&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=xtrp&action=view&page=-7  width='300' align='top'></a></td><td>Canvas after replacing DB28 with DB10</td></tr></table>
<!-- Author: anyes -->
<!-- Comment: Sun Jun 12 15;37;55 comment by...Kevin -->
<pre>The CMU and CMX errors are a single stuck bit on databoard 10.  The bit is board 6, wedge a pT(3), which maps to board 5, wedge B pT(3).  Since the bit is always on, it gives a very slight overefficiency, which won't hurt.   Since it shows up in all four phases of CMU and CMX output on every event, it can be stuck anywhere from stage 1 on downstream.   The dirac error is also a bit high, but it is a lower rate, so it could be a RAM.   This is one of the early databoards, so I'm not surprised that it developed a few problems of this type.</pre>
<!-- Date: Sun Jun 12 14:56:42 2005 -->
Run 199250: cosmic with track, remove the fake track & have all the XFT linker crate. (savee that config as PinError file)<BR> 
Looks like it all clean (see plot)... Either I am very lucky.... or you guys don't have a nice touch with this crate :-) 
  
<!-- Author: Anyes -->


<!-- Date: Sun Jun 12 14:57:42 2005 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=xtrp&action=view&page=-8&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=xtrp&action=view&page=-8  width='300' align='top'></a></td><td>Cosmic run (not fake track), XFT linker crate booked</td></tr></table>
<!-- Author: Anyes -->




<!-- Date: Mon Jun 13 15:09:22 2005 -->
<pre>Transverse Mass firmware testing (6/13/05) 
 
199276 Control with Physics Table and simtracks_MT_2pi 
199278 Test_MT with library phi0d and        " 
199280 phi0d library with Physics Table and  " 
199282 phi0d library with Physics Table and LL_errors 
199285 phi0c/lvX_d4.mcs with Physics Table and LL_errors  
199289 default lib, Physics Table, simtracks_marino (one LL_error) 
 
d4 firmware shows significant reduction in LL_errors 
2pi crossing errors are corrected with d3 firmware 
Need to be sure simulation matches library</pre>
<!-- Author: Christopher -->


<!-- Date: Wed Jun 15 17:15:18 2005 -->
<pre>DB Testing for slot 12: 
 
DB-10: 199419 - cosmics/pinerror 
DB-10: 199420 - physics/simtracks 
Errors gone - becomes secondary spare due to potential muon over-efficiency 
 
DB-28: 199421 - physics/simtracks 
DB-28: 199422 - cosmics/pinerror 
No errors found - primary spare  
 
DB-19: 199426 - physics/simtracks 
DB-19: 199427 - cosmics/pinerror 
No errors found - left as default</pre>
<!-- Author: Christopher -->


<!-- Date: Mon Jun 27 14:32:24 2005 -->
<pre>The single-pin-like error in board 1 appears to be caused by 7c0-&gt;7d0 in segment 3 when there is a track in segment 5 with the first Pt bit high.  Segment 5 Pt information precedes segment 3 Pt information on the same pin. </pre>
<!-- Author: Christopher -->


<!-- Date: Thu Jul 21 10:27:31 2005 -->
<pre>Testing new checksum library....  
 RUN      CHECKSUM       TABLE 
201452       7ffe       Physics_3_05 
201453       1770       Physics_3_05 
  -          9078       Physics_3_06 
  -          5fc8       Highlum_3_05 
  -          5fc8       Highlum_3_06 
  -          2200       Cosmics 
  -          c000       L2_torture</pre>
<!-- Author: Christopher -->
<!-- Comment: Thu Jul 21 13;35;35 comment by...Christopher -->
<pre>The high lum tables do have the same new checksum; however, they also have identical track triggers and prefred bit assignments therefore posing no threat of crossing trigger bits.  </pre>


<!-- Date: Wed Aug 31 19:16:48 2005 -->
<pre>DB-022 removed from slot 10 due to flaky RAM laoding.  CMU/CMX bits all always set if error is present.  Some runs show the same thing for IMU/Dirac. 
 
DB-010 still has muon over efficiency. 
 
DB-019 put in slot 10.</pre>
<!-- Author: Christopher -->


<!-- Date: Thu Jan 19 16:30:05 2006 -->
<pre>Replacing DB-19 in slot 10 with DB-10.  Segment 99 (123-24) error strikes again.  Replace RAM in Urbana. Run 210342 before swap and Run 210347 afterwards. DB-10 does have a small muon problem as noted above. 
Run 210343 shows test of DB-030 which still has the muon errors which crashed silicon before.</pre>
<!-- Author: Christopher -->


<!-- Date: Thu Jan 19 16:32:41 2006 -->
<table><tr><td><a href=/elog/notebooks/xtrp/Thu_Jan_19_2006_163234.ps align=top><img src=/cgi/elog/det-system-elog.pl?nb=xtrp&action=view&page=-13  align='top'></a></td><td> </td></tr></table>
<!-- Author: Christopher -->


<!-- Date: Tue Jan 24 10:28:26 2006 -->
Rebuilding all the libraries for the XTRP crate<br> 
<li> /cdf/onln/code/cdfprod/xtrp/FER_SmartTrig  
<li> /cdf/onln/code/cdfprod/xtrp/ClockBVme 
<li> /cdf/onln/code/cdfprod/xtrp/DataBVme 
<li> /cdf/onln/code/cdfprod/xtrp/ThreeTrackBVme 
<li> /cdf/onln/code/cdfprod/xtrp/TwoTrackBVme 
all have _240106 as date stamp.<br> 
/cdf/onln/home/vxworks/boot/front-end/startup.xtrp has been modified to add those in<br> 
Provided the test is successful, I will them commit all this code to cvs.
<!-- Author: Anyes -->
<!-- Comment: Tue Jan 24 11;21;34 comment by...Christopher -->
<pre>Run 210586 with these new libraries was successful!</pre>


<!-- Date: Wed Jan 25 16:02:53 2006 -->
<pre>DB-019 is back from Urbana and having the "segment 123" ram replaced as well as a faulty control line repaired.  It replaces DB-010 which has a low level dirac/trigger word error in slot 10.</pre>
<!-- Author: Christopher -->


<!-- Date: Tue Apr 25 13:53:23 2006 -->
<pre>DB-010 going down to Urbana for repairs, DB-018 discovered as an extra backup board at Fermi.  It will need to be tested.</pre>
<!-- Author: Christopher -->


<!-- Date: Wed May 10 14:29:13 2006 -->
<pre>-DB-018 tested and found to be a good DB spare. 
 
-DB-030 errors confirmed and sent to Mike, board to follow. 
 
-DB-022 may have spotty muon errors: some problems appeared during above testing in slot 16; moved and checked in slot 9, and errors are gone again.  If further errors found try reseating the board.</pre>
<!-- Author: Christopher -->


<!-- Date: Wed Jun 14 15:09:51 2006 -->
<pre>Replacing DB3-019 in slot 10 with DBII-018. 
Segment 123/99 had returned in DB3-019.</pre>
<!-- Author: Christopher -->


<!-- Date: Thu Aug 3 12:42:36 2006 -->
<pre>Replaced DB-027 in slot 12 with DB-019. This should fix the intermittent single pin error we've been seeing on board 5 that we moved to board 6 last night. This error's sypmtoms were segments 13,15, and 17, pT bit 2 always low.</pre>
<!-- Author: Christopher -->


<!-- Date: Fri Sep 15 15:14:08 2006 -->
<pre>DB-027 goes back in at slot 9.  DB-022 has been having problems loading properly.  It will go back to Urbana.</pre>
<!-- Author: Christopher -->
<!-- Comment: Thu Sep 28 10;51;36 comment by...Christopher -->
<pre>DB-027 continues to show pt bit 2 errors on wedge B segments 1,3, and 5.  DB-022 has had some loose pins repaired hopefully addressing the loading problem.  Thus, DB-022 goes back into slot 3 and DB-027 comes out to have a chip replaced</pre>