<!-- Title: 09:11:39  Thu Jul 14 2005 -->
<!-- Crewchief: SVT people -->
<!-- Op1: &nbsp; -->
<!-- Op2: &nbsp; -->
<!-- Op3: &nbsp; -->
<!-- Op4: &nbsp; -->
<!-- Op5: &nbsp; -->
<!-- Op6: &nbsp; -->
<!-- Notes: -->
I was tired to scroll the previous page (Stefano)


<!-- Date: Thu Jul 14 11:25:32 2005 -->
<pre>Run 200990 GB timing measurement AMSRW + HB + TF 21 events 
Run 200991 GB timing measurement AMSRW + HB + TF ~200 events 
Run 200992 GB timing measurement AMSRW + HB + TF++ ~200 events  
Run 200993 GB timing measurement AMSRW + HB + TF++ 21 events 
TF++ running with 70MHz and 50MHz clocks</pre>
<!-- Author: Alberto & Jahred -->
<!-- Comment: Thu Jul 14 15;55;59 comment by...Alberto & Jahred -->
<pre>Those runs are bad.
We took them again:
Run 201010 GB timing measurement AMSRW + HB + TF ~400 events 
Run 201009 GB timing measurement AMSRW + HB + TF++ ~400 events</pre>


<!-- Date: Thu Jul 14 18:09:07 2005 -->
<pre> 
                                  STATUS AMSRW'S BOARDS   
--------------------------------------------------------------------------------- 
 #AMSRW  | #Serial Ted  |  #Serial Fnal | Property | 512K Mezzanine | 4M Mezanine 
         |              |               |          |                | 
  00     |   3181       |  014240-0019  | 570727   |      62        |      17 
  01     |   3182       |  014240-0025  | 570725   |      26        |      21 
  02     |   3183       |  014240-0023  | 570724   |      56        |      28 
  03     |   3178       |  014240-0021  | 570745   |      10        |      34 
  04     |   3179       |  014240-0014  | 570746   |      34        |      24 
  05     |   3180       |  014240-0029  | 570747   |      42        |      41 
  06     |   3173       |  014240-0005  | 570743   |      09        |      35 
  07     |   3174       |  014240-0013  | 570742   |      24        |      27 
  08     |   3171       |  014240-0006  | 570740   |      50        |      18 
  09     |   3172       |  014240-0018  | 570741   |      57        |      29  
  10     |   3189       |  014240-0015  | 570729   |      08        |      37 
  11     |   3188       |  014240-0027  | 570728   |      18        |      32 
</pre>
<!-- Author: Paolo -->


<!-- Date: Fri Jul 15 16:33:36 2005 -->
<pre>We took data including svt09.       
Today configuration is:       
- AMSRW with RW enabled     
- AM++ readout sorted by roadID  
- killonbit18 enabled for SVT and for svt09    
- "slow abort" i.e. wait for svt09 is active       
 
run # 201038, 201039, 201040, 201041, 
 
</pre>
<!-- Author: Alberto -->


<!-- Date: Fri Jul 15 16:54:50 2005 -->
<pre>We have installed the new patterns and constants for new beam position: 
(x=-0.0918,y=0.2007,mx=0.000582,my=-0.000133)</pre>
<!-- Author: Stefano & Barbara -->


<!-- Date: Sun Jul 17 17:36:11 2005 -->
<pre>Run 201158 - 16 (?) events timing test using AMSRW, HB, TF, bypassing GB. 
201159 - same, but timing is thru output of HB (really, the output of the HB into a merger into the GB), so ignoring the TF. Not sure if this will work. 
201160 - AMSRW/HB/TF++ @ 70 MHz Roboclock, 50 MHz FIFO read</pre>
<!-- Author: jahred -->
<!-- Comment: Sun Jul 17 17;48;09 comment by...jahred -->
<pre>201161 - AMSRW/HB/TF++ @ 40 MHz Roboclock, 40 MHz FIFO read</pre>

<!-- Comment: Sun Jul 17 18;42;56 comment by...jahred -->
<pre>Hmmm - for some reason I got different numbers of events out of each of those runs, so I will try again, looping over all 16 events a few dozen times.

201163 - TF++ 70/50
201164 - TF++ 40/40
201165 - TF
201166 - HB</pre>

<!-- Comment: Sun Jul 17 19;13;37 comment by...jahred -->
<pre>201168 is TF++ 70/50 (201163 had no data loaded)</pre>


<!-- Date: Sun Jul 17 20:01:58 2005 -->
<pre>Try a few runs slowing done the rate by changing L0 interval from 3000000 to 500000000 (as per Ted's suggestions). 
 
201170 - TF++ 70/50 
201171 - TF</pre>
<!-- Author: jahred -->
<!-- Comment: Sun Jul 17 20;25;18 comment by...jahred -->
<pre>201173 is thru HB only</pre>


<!-- Date: Sun Jul 17 22:35:16 2005 -->
<table border=0><td><tr><td bgcolor=#e0e030><pre>Sun Jul 17 20:15:20 
 
I was just told that last month, Charles Plager was trying to convince one Italian Ace that 
Pizza was invented in US ("La pizza e' stata inventata negli USA")... nice try, Charles! 
 
 - Ted</pre></td></tr></td></table>
<!-- Author: Ted -->
<!-- Comment: Sun Jul 17 22;37;36 comment by...Ted -->
this was posted in the main shift e-log. we have two Italian ACEs and one Italian CO. so the official language for this shift is
Italian...


<!-- Comment: Tue Jul 19 02;46;18 comment by...Ted  -->
<pre>======== reply from Charles Plager ========

- Mon Jul 18 12:47:08 comment by...Charles Plager --  I should be more precise - Real pizza (i.e. Chicago-style) was invented in the U.S.</pre>
<!-- Date: Mon Jul 18 09:44:28 2005 -->
<pre>========= efficiency too low ("efficienza Troppo bassa") ? ===== 
 
 
The efficiency used to be 80%.  Then it was 78$ for a while.  I presume we lost some acceptance.  Not it has been 76% for a few days.  That is 10% fewer B events.  What's changed? 
 
	Jonathan 
 
Stefano Torre wrote: 
date and time 
Mon Jul 18 00:22:29 CDT 2005 
          D^0   fit quality        =      1 
    if (fit_quality.ne.1) skip D^0 information 
        D^0  mean  (GeV/c^2)     =       1.86129 +/-  0.00022 
        D^0  sigma (GeV/c^2)     =       0.01512 +/-  0.00026 
   number of signal  D^0  events =   10403.7285 
         signal/background       =       0.8514 
       job luminosity  (nb-1)    =    2573.9890 
        D^0  crossection (nb)    =       4.0419 
       autoSVTMon   beam   position :  average x = -0.9166E-01+/- 0.94E-03  average y =  0.2040E+00+/- 0.10E-02 
    dx/dz =  0.6081E-03+/- 0.48E-05      dy/dz =  0.1183E-03+/- 0.12E-04 
  barrel      x         error         y         error    0    -0.1159E+00  0.33E-03    0.1998E+00  0.52E-03 
   1    -0.1069E+00  0.35E-03    0.2009E+00  0.50E-03 
   2    -0.9605E-01  0.18E-03    0.2026E+00  0.54E-03 
   3    -0.8708E-01  0.29E-03    0.2055E+00  0.59E-03 
   4    -0.7710E-01  0.28E-03    0.2071E+00  0.69E-03 
   5    -0.6832E-01  0.46E-03    0.2082E+00  0.75E-03 
   Run   201133  bfs.eq.1 after trigger       0 
 Run   201152  bfs.eq.1 after trigger   49136 
 Run   201154  bfs.eq.1 after trigger       0 
 Run   201155  bfs.eq.1 after trigger       0 
  # of trigger paths for SVT efficiency and track tails fract. calc.: 13 
   path        events         path  name      61        3824        EXPRESS_ELECTRON_CENTRAL_20_v-2                      65        7115        EXPRESS_W_v-5                                        66        2081        EXPRESS_W_NOTRACK_v-1                                67        4121        EXPRESS_Z_v-6                                        71        4501        JET_100_v-8                                         114        7669        MUON_CMUP18_L2_PT15_v-1                             115        7963        MUON_CMUP18_VOLUNTEER_v-2                           160        4883        ULTRA_PHOTON50_v-7                                  162           4        UPSILON_CMUP_CMX_v-10                                66        2081        EXPRESS_W_NOTRACK_v-1                               163        4763        W_NOTRACK_v-11                                      164          46        W_NOTRACK_NO_L2_v-6                                 167        3675        Z_NOTRACK_v-4                                         average SVT efficiency =  0.763 +/-  0.002 
    total number of processed events =   102741 
       SVT failures obtained from SVTSIM comparison: 
   number of SVT failures (diff. number of tracks) =   239 
   number of SVT failures (diff. track parameters) =   504 
   ratio of the total SVT failures to the number of events =  0.7232E-02 
    number of SVT tracks selected for tails fraction calc. =   74022 
   ratio of SVT tracks with abs(d) &gt; 100 mkm =  0.2787E+00 
   ratio of SVT tracks with abs(d) &gt; 120 mkm =  0.2407E+00 
   GLOBAL ERROR BITS   from end event word 
    abs_n.  abs_n./events       name of bit 
   1968      0.1915E-01       Parity Error                   101182      0.9848E+00       Lost Sync                           0      0.0000E+00       Fifo Overflow                  101322      0.9862E+00       Invalid Data                    51290      0.4992E+00       Internal Overflow               35133      0.3420E+00       Truncated Output                    0      0.0000E+00       G-Link Lost Lock                    0      0.0000E+00       bit # 16                            2      0.1947E-04       bit # 17                       101322      0.9862E+00       L2 GhostBuster decision        
 
</pre>
<!-- Author: Ted -->
<!-- Comment: Mon Jul 18 11;09;23 comment by...Ted for Stefano -->
<pre>The efficiency moved from 80%-78% because we introduced the cut on the LC.
On friday we have installed the new patterns. Actually from the cross-check we made bifore installing them, it looks like we should have gained something, so probably we have to cross-check what's going on.
Btw the cross section of the D0 looks stable, so I don't think we are loosing the 10% of B events. Moreover the effect of the LC cut on the signal is not 4%

   Stefano
</pre>


<!-- Date: Mon Jul 18 11:55:05 2005 -->
<pre>We have updated the fakehits.mapset.</pre>
<!-- Author: Stefano and Barbara -->



<!-- Date: Tue Jul 19 13:01:23 2005 -->
<pre>Try to evaluate whether SPYMON will be upset when old 
boards will disappear from the setup. 
 
Alberto created a special hwset allowing us to remove  
AMB+AMS in wedge 0 and run fakehits. 
 
After rebooting the crate took a couple of runs for 20 min approx and no problem were observed in histograms or other information sent around. 
 
Tried also to remove old GB (slot 13) from crate 06. 
We could not reproduce the problem reported last month.  
So we physically removed GB from the setup, and put it  
in crate 09/slot 7</pre>
<!-- Author: Marco Bendetto & Alberto -->


<!-- Date: Tue Jul 19 14:29:55 2005 -->
<pre>Made a new SVTVME version, namely v3_0. 
Version v3_0 includes all the changes for the upgrade. 
The new version is now current. 
I rebooted all crates to pick it up and tried it with fake hits. 
So far so good. 
This version will remain current from now on. 
v3_0 includes the new "crcmaps" program that calculates crc also for upgraded MAPS. See instructions: http://www-cdfonline.fnal.gov/svt/svtinstallconsts_20050711.html 
</pre>
<!-- Author: Alberto for all SVTVME developers -->


<!-- Date: Tue Jul 19 16:16:33 2005 -->
<pre>I updated the config mess for crates svt00-svt05 in the HW DB from rc.phys.SVTReadoutList to rc.phys.SVTPPReadoutList. 
This should be a fully backward compatible change. 
It is required in order to configure the new boards in those crates.</pre>
<!-- Author: Alberto -->


<!-- Date: Tue Jul 19 20:22:11 2005 -->
<pre>svtmon (SPYMON) package upgraded to v3_0. 
New version includes changes by Benedetto to cope 
with AMSRW/AMPP/TFPP in the SVT setup. 
This version is now the "devel" version used in  
normal SVT crates boot script. 
AMSRW spybuffer are readout End Event work error  
statistics plots and spydumps are available by default.</pre>
<!-- Author: Marco & Benedetto -->


<!-- Date: Tue Jul 19 23:03:32 2005 -->
<pre>I got paged because SVT crates did not coldstart during shotsetup. 
The nosvx.hwset was missing the default FIRMWARE key for TFs. 
BTWT, I'm going to check the default hwset for safety.</pre>
<!-- Author: Alberto -->


<!-- Date: Wed Jul 20 20:06:52 2005 -->
<pre>We took data with AMSRW and AM++ for wedge 0.  
We are getting tracks out of it. So far so good.  
run 201377</pre>
<!-- Author: Alberto -->


<!-- Date: Thu Jul 21 10:23:08 2005 -->
<center><a href='/cgi/elog/det-system-elog.pl?nb=svt&action=view&page=-347&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=svt&action=view&page=-348' ></a><a href='/cgi/elog/det-system-elog.pl?nb=svt&action=view&page=-349&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=svt&action=view&page=-350' ></a></center>
<!-- Author: Alberto -->
<!-- Comment: Thu Jul 21 10;24;04 comment by...Alberto -->
<pre>People & boards at first AMSRW and AM++ test in the real crate!</pre>


<!-- Date: Thu Jul 21 13:35:06 2005 -->
<pre>Investigation on Fifo Overflow errors reported by autosvtmon: 
 
- This is not a common issue (of course) 
- It appeared only in Run  201349 (the first of the store) 
- It is not there for any other run in past store or recent run 
- The crate status web page report a lot of unusual FIFO 
overflow error from almost all the merger input in crate b0svt06 
- The SPYMON plots for run 201349 showed no FIFO overflow  
error bit in the EoE word in any wedge but only in the  
last merger output/ fast abort merger output / GB.  
No plots are made for other mergers in crate 6. 
</pre>
<!-- Author: Marco  -->


<!-- Date: Thu Jul 21 13:41:57 2005 -->
<center><a href='/cgi/elog/det-system-elog.pl?nb=svt&action=view&page=-351&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=svt&action=view&page=-351' width='300'></a><a href='/cgi/elog/det-system-elog.pl?nb=svt&action=view&page=-352&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=svt&action=view&page=-352' width='300'></a></center>
<!-- Author: Marco -->
<!-- Comment: Thu Jul 21 13;43;11 comment by...Marco  -->
<pre>Plots showing the good (left) and bad (right) run plot
for the frequency of FIFO overflow error in End of Event word
out of the GB board.</pre>


<!-- Date: Thu Jul 21 14:25:49 2005 -->
<pre>We are getting the impossible error from crate svt06.</pre>
<!-- Author: Alberto & Stefano -->


<!-- Date: Fri Jul 22 17:21:27 2005 -->
<pre>Today we put in AMSRW and AM++ for wedge0. 
I updated hwset and mapset for default configuration. 
Then I got called by the ACE because the hwset for L2 torture and for cosmics where to be changed in order to configure svt00.</pre>
<!-- Author: Alberto -->


<!-- Date: Sun Jul 24 16:41:53 2005 -->
<pre>Today was tryng to do a run with the crate 09 but the board amsrw n. 12 gave error during the coldstart. 
Paola sais that probably is the mezzanine card and suggested to change board.  
I swapped the n. 12 with the 13 spare . 
Now the run start correctly and the board 12 is in tstsvt2.</pre>
<!-- Author: Benedetto -->


<!-- Date: Sun Jul 24 17:09:16 2005 -->
<center><a href='/cgi/elog/det-system-elog.pl?nb=svt&action=view&page=-355&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=svt&action=view&page=-355' width='300'></a><a href='/cgi/elog/det-system-elog.pl?nb=svt&action=view&page=-353&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=svt&action=view&page=-353' width='300'></a></center>
<!-- Author: Benedetto -->
<!-- Comment: Sun Jul 24 17;12;18 comment by...Benedetto -->
<pre>Plots of the same data arrivinng from W0 processed by TF in b0svt00 and and by TFPP in b0svt09 </pre>

<!-- Comment: Sun Jul 24 18;05;10 comment by...jahred -->
<pre>All I will say is:

=)</pre>


<!-- Date: Mon Jul 25 03:57:46 2005 -->
<pre>We ran vslice parassitic test on wedge0. 
We found a small rate of errors (mismatches at the road level). 
We asked to start a new run (run 201660). 
With the new run the rate of failures went down.</pre>
<!-- Author: Alberto -->


<!-- Date: Tue Jul 26 13:07:20 2005 -->
<pre>Yesterday, thanks to a big group effort, we found a bug in the AMSRW. One SSMAP location was being overwritten once in a while during SPYMON VME activity. 
This was causing about 1% error rate from wedge0. 
Yesterday evening we replaced AMSRW for w00 with a corrected firmware version, between run 201674 and 201707. 
</pre>
<!-- Author: Alberto -->


<!-- Date: Tue Jul 26 13:12:56 2005 -->
<pre>We are replacing also AMB's and AMS's from wedge 01 and wedge 02.</pre>
<!-- Author: SVT floks -->
<!-- Comment: Tue Jul 26 13;30;41 comment by...Alberto -->
New default HWSET and MAPSET installed

<!-- Comment: Tue Jul 26 15;06;55 comment by...Alberto -->
<pre>updated nosvx.hwset and stephen5.hwset as well</pre>

<!-- Comment: Tue Jul 26 15;07;58 comment by...Alberto -->
Restored fakehits file to current patterns.<br>
Using exactly 32k for w00, w01 and w02.


<!-- Date: Tue Jul 26 15:59:08 2005 -->
<pre>We have placed three couple of AMSRW and AM++ boards in the folowing wedge:  
-wedge00: AM++ 04, AMSRW 14 
-wedge01: AM++ 02, AMSRW 13 
-wedge02: AM++ 14, AMSRW 11 
 
In this moment we have 2 spare boards for AMSRW in the tstsvt2 crate: AMSRW 03 and AMSRW 04 
We have 10 spare for AM++ boards in test stand room</pre>
<!-- Author: Paolo -->


<!-- Date: Wed Jul 27 18:47:57 2005 -->
<pre>Summary of recent SVT configurations: 
run 201377: AMSRW and AM++ for wedge 0 
run 201607 to 201716: AMSRW and AM++ for wedge 0 
run 201795 to ------: AMSRW and AM++ for wedge 0, 1, 2 
 
</pre>
<!-- Author: Alberto -->
<!-- Comment: Fri Jul 29 05;36;41 comment by...Alberto -->
<pre>run 201795 to 201883: AMSRW and AM++ for wedge 0, 1, 2 
run 201947 to ------: AMSRW and AM++ for all wedges</pre>
<!-- Date: Thu Jul 28 09:23:42 2005 -->
<pre>Yesterday evening we have found large rate rate of failures (~20%) in wedge 7 barrel 4. This morning we have changed the hit finder (slot 15 crate b0svt03). We also have fixed the cabling: HF slot 14  to MRG inputC(previus connected to inputD); HF slot 15 to MRG inputD (previus connected to inputC). We have run fake hits and everything it's ok.   </pre>
<!-- Author: Alberto & Paolo -->


<!-- Date: Thu Jul 28 10:16:53 2005 -->
<pre>We have substitute the HF board 09 with the HF board 07 (crate b0svt03 slot 15). The HF 09 now is in test stand room and it must be checked. </pre>
<!-- Author: Paolo & Alberto -->


<!-- Date: Thu Jul 28 18:54:53 2005 -->
<pre>We just installed all 12 AMSRW and AM++ boards. 
We tested with fakehits and it looks ok. 
We are just waiting for data.</pre>
<!-- Author: AM++ & AMSRW team -->


<!-- Date: Thu Jul 28 18:57:06 2005 -->
<pre>We found some bit error from HB in wedge 06 (HB #4). 
Bit #13 from the road input was bad for roughly 10% of the incoming roads. </pre>
<!-- Author: Alberto & co -->


<!-- Date: Thu Jul 28 20:37:21 2005 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=svt&action=view&page=-357&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=svt&action=view&page=-357  width='300' align='top'></a></td><td>Hits distribution of the first fakehits run with the AMSRW in all the wedges. </td></tr></table>
<!-- Author: benedetto -->


<!-- Date: Thu Jul 28 21:01:23 2005 -->
<pre>We have place new AMSRW and AM++ boards in SVT crates.  
The list of the new boards in each crate is the following: 
-b0svt00 -&gt; AMSRW 14 (slot 10), AMSRW 13 (slot 19), AM++ 04 (slot 8), AM++ 02 (slot 17) 
-b0svt01 -&gt; AMSRW 11 (slot 10), AMSRW 03 (slot 19), AM++ 14 (slot 8), AM++ 013 (slot 17) 
-b0svt02 -&gt; AMSRW 04 (slot 10), AMSRW 05 (slot 19), AM++ 011 (slot 8), AM++ 06 (slot 17) 
-b0svt03 -&gt; AMSRW 08 (slot 10), AMSRW 07 (slot 19), AM++ 010 (slot 8), AM++ 08 (slot 17) 
-b0svt04 -&gt; AMSRW 02 (slot 10), AMSRW 10 (slot 19), AM++ 07 (slot 8), AM++ 03 (slot 17) 
-b0svt05 -&gt; AMSRW 06 (slot 10), AMSRW 09 (slot 19), AM++ 015 (slot 8), AM++ 09 (slot 17) 
 
We have taken two old Road Warrior spares (2126, 2124) and we change them in AMSRW spares (15, 16)  
</pre>
<!-- Author: Paolo & Stefano -->


<!-- Date: Fri Jul 29 05:18:56 2005 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=svt&action=view&page=-358&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=svt&action=view&page=-358  width='300' align='top'></a></td><td>SVT occupacy just after AMSRW and AM++ installation!</td></tr></table>
<!-- Author: Alberto -->


<!-- Date: Fri Jul 29 05:25:22 2005 -->
<center><a href='/cgi/elog/det-system-elog.pl?nb=svt&action=view&page=-359&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=svt&action=view&page=-359' width='300'></a><a href='/cgi/elog/det-system-elog.pl?nb=svt&action=view&page=-360&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=svt&action=view&page=-360' width='300'></a></center>
<!-- Author: Alberto -->
<!-- Comment: Fri Jul 29 05;30;05 comment by...Alberto -->
<pre>Left:  L2 latency with 3 out of 12 AMSRW and AM++ installed
Right: L2 latency with all AMSRW and AM++ installed 
We see about 0.6 usec timing improvement.
For the timing being the new SVT boards are running the same algorithms as before waiting for the
next installation steps!</pre>


<!-- Date: Fri Jul 29 15:26:57 2005 -->
<pre>
 
Merger b0svt07/10: EEreg=0000, FIFOMT=1111, InpEna=0000, Ena&!MT=0000
Merger b0svt07/11: EEreg=0001, FIFOMT=1111, InpEna=0001, Ena&!MT=0000
Merger b0svt00/07: EEreg=0000, FIFOMT=1111, InpEna=1111, Ena&!MT=0000
Merger b0svt00/16: EEreg=0000, FIFOMT=1111, InpEna=1111, Ena&!MT=0000
Merger b0svt01/07: EEreg=0000, FIFOMT=1111, InpEna=1111, Ena&!MT=0000
Merger b0svt01/16: EEreg=0000, FIFOMT=1111, InpEna=1111, Ena&!MT=0000
Merger b0svt02/07: EEreg=0000, FIFOMT=1111, InpEna=1111, Ena&!MT=0000
Merger b0svt02/16: EEreg=0000, FIFOMT=1111, InpEna=1111, Ena&!MT=0000
Merger b0svt03/07: EEreg=0000, FIFOMT=1111, InpEna=1111, Ena&!MT=0000
Merger b0svt03/16: EEreg=0000, FIFOMT=1111, InpEna=1111, Ena&!MT=0000
Merger b0svt04/07: EEreg=0000, FIFOMT=1111, InpEna=1111, Ena&!MT=0000
Merger b0svt04/16: EEreg=0000, FIFOMT=1111, InpEna=1111, Ena&!MT=0000
Merger b0svt05/07: EEreg=0000, FIFOMT=1111, InpEna=1111, Ena&!MT=0000
Merger b0svt05/16: EEreg=0000, FIFOMT=1111, InpEna=1111, Ena&!MT=0000
Merger b0svt06/08: EEreg=0000, FIFOMT=1111, InpEna=1111, Ena&!MT=0000
Merger b0svt06/16: EEreg=1100, FIFOMT=0010, InpEna=1111, Ena&!MT=1101
Merger b0svt06/18: EEreg=0000, FIFOMT=1111, InpEna=1111, Ena&!MT=0000
Merger b0svt06/20: EEreg=1001, FIFOMT=0100, InpEna=1110, Ena&!MT=1010
 
Ena&!MT summary: 000000000000000b05
 
</pre>
<!-- Author: svt whodunnit script -->



<!-- Date: Fri Jul 29 16:39:17 2005 -->
<pre>We run with AMSRW and AM++ ok up to run 201948. 
We were having some failures from W7B4 and W7B5. 
After run 201948 we swap VTM for HF in slot 13 and 15 crate b0svt03. This did not solve the problem run 201963. 
</pre>
<!-- Author: SVT group -->
<!-- Comment: Fri Jul 29 16;57;29 comment by...Alberto, Paolo & Mauro -->
<pre>Then we swaped the firbers going to those 2 HF (slot 13 and 15 crate b0svt03). The fiber swap has been coordinated with the software by swaping the HW DB metakeys for those 2 HF.

The procedure for the swap is:
- update HW DB entries
- end run and go to IDLE
- refresh from DB in run control
- check that the metakeys have actually been changed
- shepherd crate
- and then GO</pre>

<!-- Comment: Sat Jul 30 12;49;36 comment by...Alberto -->
<pre>run with swaped fibers are 201969 and following</pre>


<!-- Date: Tue Aug 2 09:09:32 2005 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=svt&action=view&page=-361&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=svt&action=view&page=-361  width='300' align='top'></a></td><td>The latest AMChip batch...</td></tr></table>
<!-- Author: Alex -->


<!-- Date: Tue Aug 2 12:31:24 2005 -->
<table><tr><td><a href=/elog/notebooks/svt/Tue_Aug__2_2005_123109.ps align=top><img src=/cgi/elog/det-system-elog.pl?nb=svt&action=view&page=-365  align='top'></a></td><td>The first 2641 events emulated with svtsim within SPYMON  
show no error in number of roads out of the AMSRW 
from crate b0svt09.</td></tr></table>
<!-- Author: Marco & Benedetto -->


<!-- Date: Tue Aug 2 12:57:18 2005 -->
A Sample of svtsim/real comparision from SPYMON : 
<br> 
 
<br><span style="font-family: courier;">Event input data:</span><br 
style="font-family: courier;"> 
<span style="font-family: courier;">64104d 1456c0 2eb54b 145870 2a55a3 
140070 2ed8e4 2002c8 208f28 29a7b8</span><br 
style="font-family: courier;"> 
<span style="font-family: courier;">210238 218a78 21025c 29a798 259008 
218958 210288 2550a0 2102a8 251538</span><br 
style="font-family: courier;"> 
<span style="font-family: courier;">258dc8 29a778 2102f6 21884f 210318 
299ba8 258d08 299648 25c800 255578</span><br 
style="font-family: courier;"> 
<span style="font-family: courier;">2103de 2d03a8 290288 21c690 290a89 
21c650 290e78 2106a2 299503 258378</span><br 
style="font-family: courier;"> 
<span style="font-family: courier;">2600f8 26951c 228a95 2200bf 26011b 
2a01d8 228968 2aa5c8 2693bc 2aa408</span><br 
style="font-family: courier;"> 
<span style="font-family: courier;">2206a8 228938 2a0218 2aa028 2206ca 
22890e 26caa0 2645a0 2281c8 268a58</span><br 
style="font-family: courier;"> 
<span style="font-family: courier;">268a38 2281a8 268a18 2a24af 2a9ff8 
2a2788 2a9fd8 268948 2a998b 268928</span><br 
style="font-family: courier;"> 
<span style="font-family: courier;">2a9968 2ad470 2ea6ac 2e60e0 2edc20 
2a8478 26870d 2682b8 32ad21 2e9bad</span><br 
style="font-family: courier;"> 
<span style="font-family: courier;">329edf 2e9b88 328056 2e80aa 2a8076 
26c210 240256 28a4da 30ae18 24cbe0</span><br 
style="font-family: courier;"> 
<span style="font-family: courier;">208238 20057e 208208 240288 24cb80 
2403f8 2081e8 2ca05f 2414e8 2488e0</span><br 
style="font-family: courier;"> 
<span style="font-family: courier;">241508 2c8ba2 2488ab 2895ba 288c98 
248508 288a18 2889f8 2c0ca8 24c4d0</span><br 
style="font-family: courier;"> 
<span style="font-family: courier;">2c0cc8 30ab01 309038 309018 3088b8 
258358 2184e8 2d11d8 2924b8 2d1a98</span><br 
style="font-family: courier;"> 
<span style="font-family: courier;">2d98bb 311148 3111a8 3115f8 311e98 
640173</span><br style="font-family: courier;"> 
<span style="font-family: courier;">outputsim&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
real output</span><br style="font-family: courier;"> 
<span style="font-family: courier;">&nbsp; 
20496d&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 20496d</span><br 
style="font-family: courier;"> 
<span style="font-family: courier;">&nbsp; 
204cb8&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 204cb8</span><br 
style="font-family: courier;"> 
<span style="font-family: courier;">&nbsp; 
2021e7&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 2021e7</span><br 
style="font-family: courier;"> 
<span style="font-family: courier;">&nbsp; 
20235f&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 20235f</span><br 
style="font-family: courier;"> 
<span style="font-family: courier;">&nbsp; 
2059c4&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 2059c4</span><br 
style="font-family: courier;"> 
<span style="font-family: courier;">&nbsp; 
206ddf&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 206ddf</span><br 
style="font-family: courier;"> 
<span style="font-family: courier;">&nbsp; 
207b47&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 207b47</span><br 
style="font-family: courier;"> 
<span style="font-family: courier;">&nbsp; 
207fd2&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 207fd2</span><br 
style="font-family: courier;"> 
<span style="font-family: courier;">&nbsp; 
640073&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 640073</span><br 
style="font-family: courier;"> 
<span style="font-family: courier;">Event input data:</span><br 
style="font-family: courier;"> 
<span style="font-family: courier;">64014d 140170 2d4008 148d30 2ce8c9 
259548 218e93 210df8 29a78c 2a9ff8</span><br 
style="font-family: courier;"> 
<span style="font-family: courier;">228815 22042b 26006f 268f48 2a9fd8 
2a0ad8 2282e8 260628 268c54 2282ab</span><br 
style="font-family: courier;"> 
<span style="font-family: courier;">2ea873 228288 268a58 26108a 224e48 
2281c8 2a2778 2281a8 200798 240098</span><br 
style="font-family: courier;"> 
<span style="font-family: courier;">24d340 30aee5 2400c8 2ca1d8 2007f8 
2411d8 284710 2c2078 24d2e8 2411fa</span><br 
style="font-family: courier;"> 
<span style="font-family: courier;">28e5a0 30314e 2417d6 2417f8 24c4f0 
285fa8 2c2b48 2c2e0e 2c2fc8 24c4a0</span><br 
style="font-family: courier;"> 
<span style="font-family: courier;">2c2fe8 30abc8 309038 309018 308533 
250052 2da880 210e18 218c47 210f68</span><br 
style="font-family: courier;"> 
<span style="font-family: courier;">250928 259101 29a1d8 2d07d8 29025a 
218a4e 258f38 218988 291e98 250978</span><br 
style="font-family: courier;"> 
<span style="font-family: courier;">2586d8 25126e 2d9dc8 2998c8 2586ab 
2990a2 2d9863 21c480 2d8fed 2515c3</span><br 
style="font-family: courier;"> 
<span style="font-family: courier;">258398 218008 2d8dc8 2d8d58 299012 
298b9c 3110b8 311598 298928 228148</span><br 
style="font-family: courier;"> 
<span style="font-family: courier;">26ca20 2a9e72 2a8b28 268438 22c110 
2a8478 268416 2e0a98 2e0b30 2e0c60</span><br 
style="font-family: courier;"> 
<span style="font-family: courier;">2e0ca8 2e0cd6 32b373 2e0e60 2087d8 
6c1138</span><br style="font-family: courier;"> 
<span style="font-family: courier;">outputsim&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
real output</span><br style="font-family: courier;"> 
<span style="font-family: courier;">&nbsp; 
200156&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 200156</span><br 
style="font-family: courier;"> 
<span style="font-family: courier;">&nbsp; 
2001d8&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 2001d8</span><br 
style="font-family: courier;"> 
<span style="font-family: courier;">&nbsp; 
200259&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 200259</span><br 
style="font-family: courier;"> 
<span style="font-family: courier;">&nbsp; 
20034c&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 20034c</span><br 
style="font-family: courier;"> 
<span style="font-family: courier;">&nbsp; 
200882&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 200882</span><br 
style="font-family: courier;"> 
<span style="font-family: courier;">&nbsp; 
203779&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 203779</span><br 
style="font-family: courier;"> 
<span style="font-family: courier;">&nbsp; 
204adb&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 204adb</span><br 
style="font-family: courier;"> 
<span style="font-family: courier;">&nbsp; 
6c1138&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 6c1138</span><br 
style="font-family: courier;"> 
<span style="font-family: courier;">6c013e 1403a0 2e301f 142af0 2a12c8 
29a788 228ff8 2aa6c8 2697c8 2eadf8</span><br 
style="font-family: courier;"> 
<span style="font-family: courier;">26945e 228d89 2206e9 2409f6 204140 
309c2a 240a2b 2001d9 280708 309be8</span><br 
style="font-family: courier;"> 
<span style="font-family: courier;">280788 2414e8 2106f5 2587fb 2d0698 
290580 3113f8 254d50 21072b 254d90</span><br 
style="font-family: courier;"> 
<span style="font-family: courier;">2587c1 29a558 290888 29a536 2994a8 
2582d8 2d11ac 254dd0 2908aa 291d08</span><br 
style="font-family: courier;"> 
<span style="font-family: courier;">291d48 298d52 2d9408 292338 2d1bb7 
292360 311418 2d2b57 3121d8 2924b8</span><br 
style="font-family: courier;"> 
<span style="font-family: courier;">313098 2d2b98 3131f5 26136b 2a2788 
228422 2ea6b8 2aa1d5 2617c8 26d3c0</span><br 
style="font-family: courier;"> 
<span style="font-family: courier;">2281c8 2ea0a8 2281a8 2ea086 268728 
2a9ff8 2686f8 2a9fd8 2e8ae2 2e29a6</span><br 
style="font-family: courier;"> 
<span style="font-family: courier;">2ad6c8 2e83c8 2685e3 32aad8 32aab8 
2a8b2a 328cb8 2a89c8 2a8478 2a8458</span><br 
style="font-family: courier;"> 
<span style="font-family: courier;">241508 2c803c 2c0f68 301888 309038 
309018 31321d 2d2c7e 740153</span><br style="font-family: courier;"> 
<span style="font-family: courier;">outputsim&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
real output</span><br style="font-family: courier;"> 
<span style="font-family: courier;">&nbsp; 
20165c&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 20165c</span><br 
style="font-family: courier;"> 
<span style="font-family: courier;">&nbsp; 
201712&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 201712</span><br 
style="font-family: courier;"> 
<span style="font-family: courier;">&nbsp; 
2064ad&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 2064ad</span><br 
style="font-family: courier;"> 
<span style="font-family: courier;">&nbsp; 
740053&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 740053</span><br 
style="font-family: courier;"> 
<br>  
<!-- Author: Marco & Benedetto -->


<!-- Date: Wed Aug 3 17:46:01 2005 -->
<pre>Run 202159 ACTIVATE: RunSet: SVT_B0SVT09_STANDALONE debugging timing measurements on svt09</pre>
<!-- Author: Alberto -->


<!-- Date: Wed Aug 3 21:52:42 2005 -->
<pre>Test run 202175 includes b0svt09 for readout with TF++.</pre>
<!-- Author: jahred -->


<!-- Date: Wed Aug 3 22:36:19 2005 -->
<pre>We are having problems with svt09 and the RT server.  
Usually we get RT server errors messages when:  
- power cycling svt09 for test purposes  
- or last week beacuse of a misconfiguration of the crate  
  i.e. one library was not getting loaded at boot  
 
BUT now we got errors from the RT serverm while running in stable conditions. Does anybody knows why 
we were getting this error? </pre>
<!-- Author: Alberto & Jahred -->
<!-- Comment: Wed Aug  3 22;38;16 comment by...Alberto & Jahred -->
<a href=
'http://www-cdfonline.fnal.gov/cgi/elog/elog.pl?nb=2005&action=view&page=645&frame=2&anchor=22:35:44.047'>
here is the full entry with the lof from svt09 console</a>


<!-- Date: Thu Aug 4 00:08:31 2005 -->
<a href= 
'/cgi/elog/elog.pl?nb=2005&action=view&page=645&frame=2&anchor=00:07:13.982'> 
Link to the preliminary plot from the test run with readout of b0svt09 and the TF++</a>
<!-- Author: jahred and alberto -->


<!-- Date: Thu Aug 11 20:30:24 2005 -->
<pre>I have updated the SVTVME software to version 3_1.</pre>
<!-- Author: Alberto -->


<!-- Date: Fri Aug 12 11:43:13 2005 -->
<pre>I checked out 4 more Pulsar boards as SVT spares. 
They are pulsar # 3175, 3176, 3184, 3185.</pre>
<!-- Author: Alberto -->


<!-- Date: Sat Aug 13 18:05:40 2005 -->
<pre>Created and declared version 3_1 of svtmon (SPYMON). 
This includes the first attempt to support svtsim emulation  
in the crate and other upgrade related improvements from Benedetto. 
AMSRW/TFPP are partially supported (missing some feature  
not yet implemented in hardware). 
This version is compiled using current svtvme.  
As soon as people are OK I suggest to move the devel  
link to point to this version. It has been tested for 2 days 
without a crash on b0svt05.</pre>
<!-- Author: Marco  -->


<!-- Date: Sat Aug 13 18:56:18 2005 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=svt&action=view&page=-366&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=svt&action=view&page=-366  width='300' align='top'></a></td><td>Few errors spotted in this run from TF in wedge 11 & 10</td></tr></table>
<!-- Author: Marco  -->


<!-- Date: Tue Aug 16 00:51:22 2005 -->
<pre>We swaped boards in crate svt07 and svt06 in order to get ready for TF++ installation. 
While checking out with fakehits we found that AMSRW #0001 in wedge 00 did not coldstart due to AMmap problems. 
Originally we swaped the board with AMSRW #3182. 
But it failed again.... Then we found that the crcs in the fakehits file were wrong. 
After some thinking... svtvme was updated last week with a patch to the AMmap generation. 
Since the crcs were not recalculated at that time the patched AMmap was never loaded on boards. 
We recalculated crcs for fakehits and default mapset. 
</pre>
<!-- Author: Alberto & Paolo -->


<!-- Date: Tue Aug 16 16:57:51 2005 -->
<pre>We noticed that svt06 was doing coldstart twice for each config transition in Run Control. 
One of the mergers in svt06 was assigned to component STX, minibank 8 while all others are minibank 7. 
This cause a configuration message with double information and then coldstart twice. 
We changed the minibank for merger in slot 4 to minibank 7. 
I guess this was the case since long ago.</pre>
<!-- Author: Alberto & Paolo -->


<!-- Date: Fri Aug 19 10:59:04 2005 -->
<pre>A few days ago we move 13 AUX cards for HB++ in one of the big locker at 3rd floor.</pre>
<!-- Author: Alberto & Paolo -->


<!-- Date: Fri Aug 19 22:03:04 2005 -->
<pre>Summary of today SVT work: 
- changed default SPYMON version to v3_1 
- changed AMSRW firmware to v1_1 
  include DAQ buffer for roads 
- recompiled SVTVME code v3_1</pre>
<!-- Author: Alberto -->


<!-- Date: Fri Aug 19 22:50:03 2005 -->
<pre>SVT fakehits 203081 
SVT fakehits 203082 with STDD readout ( AMSRW road DAQ timing only) 
SVT fakehits 203083 with STDD readout ( AMSRW road DAQ timing&roads only) but it did fail because of done timeouts from svt00 and svt05. 
</pre>
<!-- Author: Alberto -->


<!-- Date: Tue Aug 23 12:11:14 2005 -->
<pre>Quick summary of this morning's SVT work:  
 
- Removed 4 old RW boards from b0svt06 that were not being used, replaced them with 4 TF++ that will 
ultimately be for wedges 04,06,08 and 10.  
 
 
- Changed CONFIGMESS setting for b0svt06 to use the same setting as bsvt00-05 (enabling support for 
SVT upgrade boards)  
 
 
- Ran fakehits with old system and new CONFIGMESS setting (was good, so we have left this in)  
 
- Then we swapped HF cables for above 4 wedges and ran fakehits with 4 TF++ boards. Histograms 
looked good.  
 
 
- Finally, we put back the cables, removed the online setting in HWDB for TF++, and ran fakehits 
again to confirm that the system was working as before. The 4 boards TF++ remain in the crate, 
though they should not yet be included in RC except by an SVT expert.</pre>
<!-- Author: jahred, alberto, paolo -->


<!-- Date: Wed Aug 24 08:39:37 2005 -->
<pre>Since run 203163 we are reading out the STDD bank. 
Now it contains timing information for roads getting out of AMSRWs. 
It will contain additional timing info.</pre>
<!-- Author: Alberto & Paolo -->


<!-- Date: Fri Aug 26 11:50:47 2005 -->
<pre>We swaped HF # 007 that was in slot 15 crate b0svt03, currently (i.e after fiber swap) taking care of W7B0 and W7B1, with an HF from the 3rd floor locker.</pre>
<!-- Author: Alberto & Federico -->
<!-- Comment: Wed Aug 31 18;09;19 comment by...Alberto -->
<pre>I replaced HF # 041 that was in slot 15 crate b0svt03 with HF # 048 that has version "v20000000" as all other HFs.
The previous two HFs used there (i.e. #041 and #007) did have differen versions. </pre>


<!-- Date: Wed Aug 31 23:33:27 2005 -->
<pre>We marked spare AMSRW # 00 (i.e. pulsar #3181) as bad. 
It has problems coldstarting because of AMMap crc errors. 
Actually it works if there is no crc in the file which is strange since the write4Mmap function readsback the memory anyhow. 
May be there is a bug in write4MMap?</pre>
<!-- Author: Alberto & Paolo -->


<!-- Date: Fri Sep 2 14:41:16 2005 -->
<pre>Changed fakehits_nobypass.hwset and fakehits.mapset to use the TF++ w/32k. Moved the old files to fakehits_nobypass_old.hwset and fakehits_old.mapset in svtconf. 
 
Also, interested parties should look at  
&lt;a href= 
'/cgi/elog/elog.pl?nb=2005&action=view&page=734&frame=2&anchor=14:29:53.069'&gt; 
fakehits timing with 128k patterns &lt;/a&gt; - all of our hard work should really pay off with this improvement (hopefully soon!) 
</pre>
<!-- Author: jahred -->
<!-- Comment: Fri Sep  2 14;41;57 comment by...jahred -->
<pre>&lt;a href=
'http://www-cdfonline.fnal.gov/cgi/elog/elog.pl?nb=2005&action=view&page=734&frame=2&anchor=14:29:53.069'&gt;
Here's another try at the link &lt;/a&gt;


</pre>

<!-- Comment: Fri Sep  2 14;42;30 comment by...jahred -->
<a href=
'http://www-cdfonline.fnal.gov/cgi/elog/elog.pl?nb=2005&action=view&page=734&frame=2&anchor=14:29:53.069'>
And here it is, hopefully with me not being some stupid </a>





<!-- Date: Fri Sep 2 16:58:00 2005 -->
<pre>We swaped HF # 8 in b0svt02/slot13 (taking care of W5B0B1) 
b0svt02 Slot: 13  Id:  0008 035 SVT HitFinder v20000420  
with HF # 16 that has version v20000000.</pre>
<!-- Author: Alberto & Guido -->


<!-- Date: Sat Sep 3 14:38:23 2005 -->
<pre>I followed Marco's instructions to change the "SVT status" .ps file with plots from svtmon: 
 
setup svtmon -d 
cd $SVTMON_WWWDIR/ps_files 
edit validation_list.cfg 
 
The only things changed are that we now should point to the TFPP histograms.</pre>
<!-- Author: jahred -->


<!-- Date: Wed Sep 14 14:08:11 2005 -->
<pre>We're taking data at the end of this store with 128k patterns. So far, this is runs 204262 and 204263. Will continue thru all other runs until the end of this store.</pre>
<!-- Author: jahred -->


<!-- Date: Wed Sep 14 22:49:17 2005 -->
<pre>We tried for awhile to use a new version of svtvme that does a quick coldstart but not fully checking all 4M mezzanines. That did not succeed, so we put back the old svtvme. But we're still using 128k patterns, and we've updated fakehits.mapset to use 128k patterns.</pre>
<!-- Author: jahred, alberto, paolo -->


<!-- Date: Thu Sep 15 10:47:38 2005 -->
<pre>Some time last week SVTSIM was updated to emulate the W5B0 problem. 
Now the simulation is reproducing the hardware but the problem, i.e. une TF constant out of range, is still there.</pre>
<!-- Author: Alberto, Paolo & Jahred for the SVT group -->


<!-- Date: Fri Sep 16 01:14:13 2005 -->
<pre>While running fake hits we got 2 problems during coldstart of b0svt06.  
 
At first we loaded a mapset without all CRCs for the TF++. 
This caused all TF++addr_1 memories to be rewritten. 
TF_w06 failed! 
 
tfpp(slot12,tf_w06): mk=tf_w06, tfpp=0x68620b8 
checkMemoryFragment: nerr=61 
FER_E_SVT, writeMap(tf_w06/TF++addr_1): checkMemoryFragment mismatch (nerr=61) 
FER_E_SVT, tfpp(slot12,tf_w06): Make Addr 1 map write failed 
 
In order to solve this we did power cycle the crate. 
Then we got errors by the GB. 
 
waited 109548 cycles for FRAM 
checkMemoryFragment: nerr=1 
FER_E_SVT, writeMapGBFRAM(gb_final/GBphi): checkMemoryFragment mismatch (nerr=1) 
FER_E_SVT, GB phi map write failed 
 
A reset and shepherd did solve this second problem. 
 
</pre>
<!-- Author: Paolo & Alberto -->


<!-- Date: Fri Sep 16 03:34:39 2005 -->
<table border=0><td><tr><td bgcolor=#e0e030><pre>We have loaded a new release (v3_3) of svtvme. Now the coldstart routine is more fast.</pre></td></tr></td></table>
<!-- Author: Paolo & Alberto -->


<!-- Date: Tue Sep 20 10:16:02 2005 -->
<pre>The SVT upgrade pager is in the top drawer of the Ops Manager's desk. There's no reason for me to carry 2 pagers that serve the same, identical purpose. If any brave SVT sole wants the upgrade pager, Sung-Won said we should just take it (the pager should be marked on its side).</pre>
<!-- Author: jahred -->
<!-- Comment: Tue Sep 20 17;20;19 comment by...jahred -->
<pre>Brave soles are tasty in a light butter sauce. Brave SVT souls are a different story. =)</pre>


<!-- Date: Fri Sep 23 09:33:21 2005 -->
<pre>Since yesterday we are taking data with the final merger in non-deterministic mode.</pre>
<!-- Author: Alberto for Jahred & Roberto -->


<!-- Date: Fri Sep 23 11:36:49 2005 -->
<pre>Got more trouble with b0svt08. Crate gave a busy TO, and then during shepherd RC got stuck in the active-&gt;halt transition. Ace tried to shepherd again, with no success (an error window popped up saying that the shepher failed). But the crate looked like it shepherded OK... Aborting and starting a new run solved the problem. 
 
We had a similar problem last night. I've asked the aces to paste the text of the console into an email to me to help us debug the problem.</pre>
<!-- Author: jahred -->
<!-- Comment: Thu Sep 29 10;10;44 comment by...jahred -->
<pre>Of course, now that we're watching for it, we haven't had this problem again. But that's usually the way things work =)</pre>


<!-- Date: Wed Oct 5 18:45:56 2005 -->
<pre>Here is a chronological list of the fun trouble that we had tonight. The ultimate goal was to swap the 5500 CPU in b0svt08 with the 2304 CPU in one of our test stands (tstsvt1). We hope that this might help solve some of the troubles that b0svt08 has been giving us. 
 
- We took over the SVT system, and removed the CPU from b0svt08. We plugged it into the CPU motherboard for tstsvt1 (everything we know says they are compatible). The CPU would not power up. 
 
- We put back the old 2304 CPU in tstsvt1, but it, too, would not power up. We examined the motherboard and found a blown fuse. 
 
- We took the 5500 CPU (and motherboard) from tstsvt2 (our other test stand), and placed it in tstsvt1. It powered up OK, but we were unable to configure it to run correctly (I think we need more help). All we were told to do was run bootChange, and follow   
http://www-cdfonline.fnal.gov/computing/vxworks/boot_parameters.html 
 
- Ivan came by at this point, looking for his test stand back. He helped us find a new fuse, and we successfully put back the original CPU in tstsvt1. 
 
- We put back the original 5500 in b0svt08, configed, and successfully ran fakehits to test the SVT system. In the meantime, we tried reconfiguring the CPU that had been moved from tstsvt2 to tstsvt1 for running again in tstsvt2. We did not succeed. We don't know if we're missing some instructions, or if there's something else we need to do. The boot settings (and boot files) for tstsvt2 look exactly as they do for b0svt09, but for some reason we cannot vxlogin into tstsvt2, which we can access only thru minicom. 
 
In the end, nothing has changed, except that we're down a test stand crate. Paolo and Jahred just ran out of ideas, emailed Frank for help, and in the end think Stefano should be responsible for fixing this. =)</pre>
<!-- Author: jahred and paolo -->


<!-- Date: Thu Oct 6 11:38:28 2005 -->
<pre>tstsvt2 is once again working. for anyone trying to set up a CPU, don't be stupid like me and not know how to get the crate IP address. Just ping the crate (ie: ping tstsvt2) and use bootCrate from minicom, and you should be fine.</pre>
<!-- Author: jahred -->


<!-- Date: Wed Oct 19 00:38:14 2005 -->
<p> 
I managed to resurrect the correct version of my 'hf.c' Hit Finder data flow test, 
which sends data from GSTM over fibers to VTM to HF, then checks HF ospy 
contents.  (There is an option to check LVDS cable output by plugging in a TF 
downstream, but I didn't use it.)  I updated firmware to latest version on all 12 
boards in the B0 test stand area, then ran the 'hf.c' test.  The test succeeded on 
these ten boards: 07 08 10 11 22 30 31 41 49 51.  The test did not succeed on 
these two boards: 09 17.  The good boards are marked with a sticker indicating, 
"OK.  WJA 2005-10-18." 
<p> 
The 'hf.c' code was in a state of confusion because I was in the middle of modifying 
hf.c to coexist on a VME CPU with the svtvme library, but I left the process incomplete at some point in 2003 when I suddenly began shopping for houses on 
the east coast.  Fortunately, I keep pretty good backups. 
<p> 
At some point soon, I'll resume the HF testing lessons, and I'll take a closer look at 
the two errant boards. 
<p> 
If any board marked "OK.  WJA 2005-10-18" fails to work in the real system, I'd like 
to see personally what is going on. 
<p>  
<!-- Author: Bill Ashmanskas -->


<!-- Date: Wed Oct 19 23:35:57 2005 -->
<pre>Run Control's history of what Hit Finders lived where. 
 
select card_cardname, updatetime, oldvalue, newvalue 
  from cardupdates where field like 'SERIALNUMBER' and 
  card_cardname like 'SVTHITFINDER%'; 
 
svthitfinder_00  svt00/04 0050 since 10/2002 
svthitfinder_01  svt00/05 0028 since 05/2003, was ? 
svthitfinder_02  svt00/06 0029 since 10/2002 
svthitfinder_03  svt00/13 0027 since 05/2003, was ? 
svthitfinder_04  svt00/14 0026 since 11/2002 
svthitfinder_05  svt00/15 0023 since 05/2003, was ? 
 
svthitfinder_06  svt01/04 0004 since 08/2000 
svthitfinder_07  svt01/05 0005 since 08/2000 
svthitfinder_08  svt01/06 0003 since 08/2000 
svthitfinder_09  svt01/13 0034 since 08/2000 
svthitfinder_10  svt01/14 0032 since 02/2002, was 0033 
svthitfinder_11  svt01/15 0033 since 02/2002, was 0032 
 
svthitfinder_12  svt02/04 0021 since 11/2002 
svthitfinder_13  svt02/05 0020 since 11/2002 
svthitfinder_14  svt02/06 0019 since 11/2002 
svthitfinder_15* svt02/13 0016 since 09/2005, was 0008 0022 0016 
svthitfinder_16  svt02/14 0014 since 09/2000 
svthitfinder_17  svt02/15 0015 since 09/2000 
 
svthitfinder_18  svt03/04 0018 since 10/2000 
svthitfinder_19  svt03/05 0044 since 10/2000 
svthitfinder_20  svt03/06 0025 since 03/2002, was 0050 
svthitfinder_21  svt03/13 0012 since 10/2000 
svthitfinder_22* svt03/14 0043 since 07/2004, was 0010 
svthitfinder_23* svt03/15 0048 since 08/2005, was 0041 0009 0007 
 
svthitfinder_24  svt04/04 0039 since 08/2000 
svthitfinder_25  svt04/05 0036 since 08/2000 
svthitfinder_26  svt04/06 0024 since 08/2000 
svthitfinder_27  svt04/13 0013 since 08/2000 
svthitfinder_28  svt04/14 0038 since 08/2000 
svthitfinder_29  svt04/15 0035 since 08/2000 
 
svthitfinder_30* svt05/04 0006 since 01/2004, was 0008 0043 0048 
svthitfinder_31  svt05/05 0037 since 08/2000 
svthitfinder_32  svt05/06 0045 since 08/2000 
svthitfinder_33  svt05/13 0046 since 08/2000 
svthitfinder_34  svt05/14 0040 since 02/2002, was 0042 
svthitfinder_35  svt05/15 0042 since 02/2002, was 0040 
</pre>
<!-- Author: Bill -->
<!-- Comment: Wed Oct 19 23;43;07 comment by...  -->
<pre>Boards removed after having run for some time (less likely to
be simple case of wrong firmware):

0007 moved 2005-07-28, 2005-08-26
0008 moved 2004-01-07, 2005-07-06, 2005-09-02
0009 moved 2005-07-28
0010 moved 2004-07-29

</pre>