<!-- Title: 10:25:38  Tue Nov 14 2006 -->
<!-- Crewchief: Stefano -->
<!-- Op1: &nbsp; -->
<!-- Op2: &nbsp; -->
<!-- Op3: &nbsp; -->
<!-- Op4: &nbsp; -->
<!-- Op5: &nbsp; -->
<!-- Op6: &nbsp; -->
<!-- Notes: -->
<h2>A new era with O(10-4) failures</h2>


<!-- Date: Tue Nov 14 10:27:08 2006 -->
<pre>Today I've installed new patterns for beam position 
x=-0.1157 
y=0.06027 
dx/dz=0.0003995 
dy/dz=0.0000143</pre>
<!-- Author: Stefano -->


<!-- Date: Tue Nov 14 10:38:35 2006 -->
<pre>Today we tryed to use tstsvt2. 
It was not booting with message "could not read file boot/front-end/startup.5500.cdf". 
The problem was that the crate could not login on online machines, because the tstsvt2.table file was wrong. 
In particular it was still doing "setup svtmon -d" which was failing, this failure did not allow he crate to login and then to boot. 
This is particularly tricky because the error, does not give any hint about what the problem is</pre>
<!-- Author: Alberto & Geum Bong -->


<!-- Date: Wed Nov 15 18:14:48 2006 -->
<pre>&lt;h4&gt;Today SVT tests&lt;/h4&gt; 
- Geum Bong tried a new version of the beam width fitter with fake hits. The test was fine so is going to ask for an end of store test&lt;br&gt; 
- I've tested a new vesion of SPYMON. It was not fitting the beam position so I went back to default verion and tested it with the fake hits.</pre>
<!-- Author: Stefano -->


<!-- Date: Wed Nov 15 19:29:03 2006 -->
<pre>We have added 3 HF in b0svt09 to try to solve the problem of the garbage sent to the EVB from b0svt09. </pre>
<!-- Author: Stefano & Alberto -->


<!-- Date: Thu Nov 16 07:41:11 2006 -->
<h2> I was paged </h2> 
<p> 
b0svt09 was sending bad data to EVB. I had ACE reseat Tracer and ghostbuster. 
</p>
<!-- Author: Taichi -->


<!-- Date: Tue Nov 21 12:03:21 2006 -->
<h2>I was paged</h2> 
<h3>SVT BC in the SVTD Bank is different different from SVT BC sent to the L2</h3> 
<p>I reseated Ghostbuster and fixed it. But HRR is enough to remove this error. I swapped the spare Ghostbuster to main Ghostbuster with new firmware to see if this kind of problem go away temporally. </p>  
<!-- Author: Taichi -->


<!-- Date: Tue Nov 21 17:08:16 2006 -->
<p> 
We asked to mark bad for these run sections due to mismatches between SVT bunch counter and L2 bunch counter. 
<ul> 
<li> Event 26318261 to 26334645 in run 228429 
<li> Event 4950424 to 5009562 in run 228449 
</ul> 
</p>
<!-- Author: Taichi -->


<!-- Date: Mon Nov 27 04:41:08 2006 -->
<h3>I was paged</h3> 
Again mismatches beween SVT BC in SVTD and L2 bank. I got paged when the error was already <a href= 
'/cgi/elog/elog.pl?nb=2006&action=view&page=897&frame=2&anchor=04:23:06.567'> 
cleared</a>
<!-- Author: Stefano -->
<!-- Comment: Tue Nov 28 08;59;22 comment by...Stefano -->
<pre>The first event in StreamD with BC mismatch is 7612736.
The last event is 7747493. 
The next HRR occurred at 7938344. I would use this as last bad event.
Note that at event 7747139 and HRR was issued by the shift crew and the error was not cleared
</pre>


<!-- Date: Tue Nov 28 12:36:19 2006 -->
<pre>I reprogramed AMSRW #08, AM++ #17 and AM++ #15 with the default firmware, instead of previous test firmware. 
 
AMSRW #08 and  AM++ #17 test good. 
While AM++ #15 shows some missing roads.</pre>
<!-- Author: Alberto -->


<!-- Date: Tue Nov 28 12:47:32 2006 -->
<pre>AM++ #15 installed with Jumpers set to 1111 is failing on the following addresses: 
0713a5 (wrong laymap 200037 instead of 20003f) 
0712ae (missing, expeted laymap is 20002f) 
071c97 (missing, expeted laymap is 20003e) 
07169e (extra, laymap is 20002f) 
07110d (extra, laymap is 20002f) 
071b24 (extra, laymap is 20002f) 
 
This indicates that the problem is on lamb #0, column #3 and chip #2.</pre>
<!-- Author: Alberto -->


<!-- Date: Wed Nov 29 11:17:31 2006 -->
<h3>Today SVT work</h3> 
We moved the b0svt09 crate in tstsvt2. To do that we moved the CPU and the connections between SVT crates. <br> First Ray Culbertson checked that tstsvt2 was able to send data to VRB. <br> Bill Badget changed DB entries for tstsvt2 and b0svt09. <br> After setting up the cables we ran a fake hits test with SEVB and Beam Fitter enables and everything looked fine. <br> Now we are running with the new crate. The shift crew should not see changes in the behavior of SVT.<br>We expect with this change to have solved the problem of SVTD BC mismatches and SVT sending bad data to the EVB.<br> 
I've to ask Bill to check if we can use tstsvt2 for tests. As of now the crate is off <br> 
During Fake Hits run we had some errors coming from SPYMON regarding the readout of Merger SPYBUFFER in slot 11<br>
<!-- Author: Stefano -->


<!-- Date: Sat Dec 2 14:34:30 2006 -->
<h2>I was paged</h2> 
I've been paged because one Memory of the TF++ in W8 (crate b0svt06) was corrupted: 
 
<pre> 
When restart run, we get the error :   
MLE) b0svt06:Messenger:Dec 1, 2006 02:20:25 PM->FER_E_SVT, write4MMap(tf_w08/TF++P3P4P5): 
checkMemoryFragment   
 
(MLE) b0svt06:Messenger:Dec 1, 2006 02:20:25 PM->FER_E_SVT, mismatch (nerr=377)  
 
(MLE) b0svt06:Messenger:Dec 1, 2006 02:20:25 PM->FER_E_SVT, write4MMap(tf_w08/TF++P3P4P5): 
checkMemoryFragment   
 
(MLE) b0svt06:Messenger:Dec 1, 2006 02:20:25 PM->FER_E_SVT, mismatch (nerr=377)  
 
(MLE) b0svt06:Messenger:Dec 1, 2006 02:20:25 PM->FER_E_SVT, TFPP (slot 17) Intcp_2 write failed 
twice  
 
 
(MLE) b0svt06:Messenger:Dec 1, 2006 02:20:25 PM->Setup failed with error code 1  
(MLE) b0svt06:Messenger:Dec 1, 2006 02:20:25 PM->Statechange failed  
 
</pre> 
 
<p> I powercicled the crate so that the TF++ was forced to check and overwrite all the memory location - It worked 
<!-- Author: Stefano -->
<!-- Comment: Sat Dec  2 15;19;56 comment by...Jahred -->
I have seen this happen a few times on random boards with random memories. Not sure how or why it happens, but power-cycling does solve the problem, so I think that was the thing to do. If it happens to the same board/memory, we can swap things. Otherwise I think we keep things the same ....

<!-- Comment: Sun Dec  3 14;27;20 comment by...jahred -->
<pre>To be more clear, one can first try config again (a quick and not bad option). If that fails, I think power-cycling the crate is the best option.</pre>


<!-- Date: Mon Dec 11 15:06:32 2006 -->
<h2> Today works </h2> 
 
- Benedetto tested the new version of SPYMON (v4_0) since the test was fine it is now the current version.<br> 
- Me and Taichi: we clean up b0svt09 and moved all the boards needed to test the BG in tstsvt2.<br> 
- Taichi tried test scripts and they worked so it looks like we have the tstsvt2 crate back<br> 
- The 3 HF we moved to B0svt09 to check backplane capacitance are now in the teststand area<br> 
- The TF W00 that used to be in tstsvt2 is now in the teststand room<br>  
<!-- Author: Stefano Taichi & Benedetto -->


<!-- Date: Fri Jan 19 19:03:09 2007 -->
<br> <b>Summary of New Alignment Work :</b> 
<br> - Today, we tested new mapset (with new alignment): Run 232445. 
<br> - You can find results in <a href="http://hep.uchicago.edu/~kohei/SVT/new_alignment_plot_01192007/run232445/"> here</a>. 
<br> - Since everything seems pretty normal and even I found efficiency increase (75.4%), together with L3 people (Veronique and Dave), we set new one as a default from Run 232493. 
<br><br>  
<!-- Author: Kohei -->


<!-- Date: Fri Feb 9 11:19:21 2007 -->
<pre>New patterns installed. 
x=-0.1262, y=0.0392, dx/dz=0.0003513, dy/dz=0.0000747 
the beam is already off this beam position 
let's wait offline report to understand if we have recovered the efficiency</pre>
<!-- Author: Stefano -->


<!-- Date: Wed Feb 14 18:52:16 2007 -->
<pre>&lt;h1&gt;I was paged&lt;/h1&gt; 
SVT was not fitting the beam for runs 234302,234313,234314 
The reason for this is that b0svt07 was freezing all the crates avoiding the SPYBUFFER to be filled with the tracks. In this way the beam fitter was not finding enough tracks to perform the fit of the beam. 
The reason that caused the b0svt07 to freeze is not clear. 
The plot 2.3.4: L2_Table_Beam has to be considered bad as soon as it become RED, indipendently on what is written in the table. There is a bug and we need to fix it.</pre>
<!-- Author: Stefano & Marco -->


<!-- Date: Mon Feb 26 18:48:37 2007 -->
In case someone responds to a page and cannot contact me later tonight, I was called on my cell because b0svt07 was not going through config. There is a spy_fanout/XTFAss): checkMemoryFragment error that persists through multiple configs and attempts at new runs. From Chicago, I have had the ACE powercycle the crate. Keeping my fingers crossed ...
<!-- Author: jahred -->
<!-- Comment: Mon Feb 26 18;49;19 comment by...jahred -->
<pre>MLE) b0svt07:Messenger:Feb 26, 2007 06:21:50 PM-&gt;FER_E_SVT, writeMap(spy_fanout/XTFAss): checkMemoryFragment 
(MLE) b0svt07:Messenger:Feb 26, 2007 06:21:50 PM-&gt;FER_E_SVT, mismatch (nerr=94208)

(MLE) b0svt07:Messenger:Feb 26, 2007 06:21:50 PM-&gt;FER_E_SVT, XTFA (slot 17) SSMAP write failed

(MLE) b0svt07:Messenger:Feb 26, 2007 06:21:50 PM-&gt;Setup failed with error code 1
(MLE) b0svt07:Messenger:Feb 26, 2007 06:21:50 PM-&gt;Statechange failed</pre>


<!-- Date: Sat Mar 17 13:58:20 2007 -->
<pre>Test Track List Board 
Today we tested the connection from the TrackList board to SVT to do that we had to unplug and plug the from XTRP.  
Everything is now in the default configuration</pre>
<!-- Author: Stefano -->


<!-- Date: Mon Mar 19 17:11:09 2007 -->
<pre>Hi DQM people, 
 
At the end of a very long run yesterday (236389), SVT had a problem where it went out of synch with the rest of the trigger. I looked at our monitoring log files this morning, and see that the problem started roughly around event 21993407 and was fixed roughly around event 22334845. 
 
From the e-log, I se that there were HRRs issued at event 21424014 and then again at 22335041 (this latter HRR was probably was fixed the system). 
 
I will have the SciCo mark this run partially OK for SVT, and will add a comment in the e-log about this as well. If you have any questions, please let me know. 
 
Best, 
Jahred 
</pre>
<!-- Author: Stefano (paste of Jahred mail) -->


<!-- Date: Tue Mar 20 18:40:49 2007 -->
<pre>Vadim was looking for a spare Pulsar, so I told him he can take 3190, which is a TF++ with bad firmware (the new firmware did not work in the board). If we need a spare for anything, keep this in mind. Vadim will find one of us to place the spare mezzanines in our locker when he gets around to taking the board.</pre>
<!-- Author: jahred -->


<!-- Date: Tue Apr 3 12:41:10 2007 -->
<pre> We did test for new GB firmware which can check the BC mismatches 
between L1 (backplane) and End of Event using fakehits. 
But, it does not provide any CDF or SVT errors. There are two  
possibilities; (1) our firmware is something wrong. or (2) EE and 
L1 BC (bunch counter) was syncronised even in fakehits. 
 
 We will investigate more</pre>
<!-- Author: Taichi and Taka -->


<!-- Date: Tue Apr 3 18:45:16 2007 -->
<pre>We have some drastic tests for having wrong BC mismatches. 
(a) sending data from different SVT crate (from tstsvt2 MRG to 
   b0svt09 GB) as suggested by Alberto.  
(b) just discinnected the input cable og GB board 
These were done under fakehits running. 
 
Both did not give any errors. We might suspect to have wrong  
algorithm in new GB firmware. 
 
We read out BC from backplane via VME read --&gt; looks fine 
We read out error register flag via VME    --&gt; flag is turned off 
 
We have to understand this phanomena more. 
We will impliment algorithm to check both backplane BC and 
End of Event BC at the same time via VME.   </pre>
<!-- Author: Taichi and Taka -->


<!-- Date: Wed Apr 4 18:05:11 2007 -->
<pre>What we learned today; 
 
Test at teststand (tstsvt1) 
(1) readout latched l1a BC and EE BC via VME at the same time 
(2) send dummy data with only one EE (End of Event) 
(3) this should cause different BCs between EE BC and L1A BC 
(4) It seems that our firmware (algorithm) works fine. If  
   we have different BCs between EE and L1A, error register bit 
   was flagged 
(5) Enabling/disabling flag was also worked. 
 
Test using fakehits  
(1) did same thing as did in teststand. All of above mechanisms 
   worked fine. 
(2) But, _cdferror, and _svterror did not cause RC error. 
   We will ask this to Bill Badget 
 
Cosmic ray run 
(1) At this case, EE BC and L1A BC should be same. However, this 
   looks different. So, we could have wrong information for 
   backplane BCs. We will contact experts for this. 
(2) There were still no errors with _svterror, and _cdferror. 
   We don't understand why. (might be our fault to translate 
   error register information to _cdferror) 
 
 In total, we had good progresses and are close to finish the  
task, but two more crucial things should be solved before 
installing. 
  
  </pre>
<!-- Author: Taichi and Taka -->


<!-- Date: Thu Apr 5 14:44:51 2007 -->
<pre>The new acnet plot with the Beam position and the angle is avilable in  
T73 pg. 15. 
The value of the position have to be the same of the Trigmon Plot.  
</pre>
<!-- Author: Benedetto -->


<!-- Date: Thu Apr 5 14:53:17 2007 -->
<center><a href='/cgi/elog/det-system-elog.pl?nb=svt&action=view&page=-379&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=svt&action=view&page=-379' width='300'></a><a href='/cgi/elog/det-system-elog.pl?nb=svt&action=view&page=-380&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=svt&action=view&page=-380' width='300'></a></center>
<!-- Author: benedetto -->


<!-- Date: Fri Apr 6 03:58:20 2007 -->
<pre>Test for new GB firmware 
 
Fakehits: 
(1) There is an offset of 0x24 between backplane BC and EE BC 
(2) Shift 0x24 for backpalne BC and then two BC are exactry same. 
(3) Tracer couldn't find error of BC even if error register is on. We have to check the propagation of _cdferror and _svterror 
 
Cosmic run: 
(1) We did same thing as fakehits and got same results as fakehits</pre>
<!-- Author: Taka and Taichi -->


<!-- Date: Fri Apr 6 15:53:43 2007 -->
<pre>SVT TEST 
We did the test of new GB firmware to check the BC mismatches between VME backplane and End of Event word. We larned that new GB send error flag when new GB catch the BC mismatches but Tracer cannot found this error flag. We have to investigate why it could happen. On the other hand, new GB should keep error flag on once after new GB catch the BC mismatch but the behavior of error flag is different from what we expected. It might be our bug. we will fix that. </pre>
<!-- Author: Taka and Taichi -->


<!-- Date: Sun Apr 15 08:33:00 2007 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=svt&action=view&page=-382&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=svt&action=view&page=-382  width='300' align='top'></a></td><td>Acnet Plot T73 in the store 5353.<br> 
Beginning luminosity 232E+30</td></tr></table>
<!-- Author: Benedetto -->


<!-- Date: Sun Apr 15 09:57:53 2007 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=svt&action=view&page=-383&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=svt&action=view&page=-383  width='300' align='top'></a></td><td>Acnet plot D44: Beam position and slope. </td></tr></table>
<!-- Author: Benedetto -->
<!-- Comment: Sun Apr 15 10;08;26 comment by...Benedetto -->
<table border=0><td><tr><td bgcolor=#e0e030><pre>1-APR-2007 00:00 until 15-APR-2007 09:54</pre></td></tr></td></table>


<!-- Date: Fri Apr 20 03:08:54 2007 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=svt&action=view&page=-385&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=svt&action=view&page=-385  width='300' align='top'></a></td><td>The beam position of the last 5 days</td></tr></table>
<!-- Author: Benedetto -->


<!-- Date: Sat Apr 21 15:56:38 2007 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=svt&action=view&page=-386&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=svt&action=view&page=-386  width='300' align='top'></a></td><td>Acnet plots</td></tr></table>
<!-- Author: Benedetto -->
<!-- Comment: Sat Apr 21 16;11;30 comment by...Benedetto -->
<pre>&lt;br&gt;&lt;b&gt;Plot of the new ACNET devices:&lt;/b&gt;&lt;br&gt;
C:B0RPOS=sqrt(dx^2 + dy^2)&lt;br&gt;
C:B0RANG=sqrt((dx/dz)^2 + (dy/dz)^2)&lt;br&gt;
(these two values starts since 20 Apr 2007 23:00)

&lt;br&gt;
Location of the page &lt;b&gt;CDF IP POSITION&lt;/b&gt;&lt;br&gt;
T73, #15, subpage LOWBETA &lt;br&gt;

 </pre>


<!-- Date: Mon Apr 23 17:28:00 2007 -->
<pre>Summary of SVT tests today: 
  - purpose is to enable in all mergers the option to generate CDFerror upon &gt;3 consecutive wrong BC. 
  - the first end of store test failed because the SVTVME code did not recognize the corresponding bit in register MRG_GCDFERR_EN 
  - Benedetto and me checked that this feature is actually working ok with 3 mergers in the teststand 
  - a new version of SVTVME with the fix is now loaded by default on the crates. This is NOT a frozen release since the change with respect to the previous v4_2 is minimal. 
  - I checked with fakehits that the new version loads correctly and that the MRG_GCDFERR_EN register gets written correctly. 
</pre>
<!-- Author: Benedetto & Alberto -->


<!-- Date: Sat Apr 28 13:00:45 2007 -->
<pre>Since today we are running with all mergers that will report CDFERROR if BC are not amtching for more than 3 consecutive events. 
MRG_GCDFERR_EN  0x100 
 
This is running fine for the time being.</pre>
<!-- Author: Annamaria & Benedetto & Alberto -->
<!-- Comment: Sat Apr 28 13;03;14 comment by...Alberto -->
<pre>The fakehits hardwareset is also updated.</pre>


<!-- Date: Thu May 3 12:03:03 2007 -->
SVT RXPT ERROR 
<p> 
We got RXPT ERROR during svt fakehits at the begining of the every run. This was caused by wrong fakehits_nobypass.hwset file. The CDF_ERROR was left active during fakehits after recent tests. 
So we changed it and the error has gone. 
</p>
<!-- Author: Alberto, Benedetto and Taichi -->


<!-- Date: Sat May 5 19:13:07 2007 -->
<pre>SVT pattern and constants has been changed 
&lt;p&gt; 
We installed new pattern and constants since beam position has been changed the day before yesterday. All seems good with this new configuration.  
&lt;/p&gt;</pre>
<!-- Author: Alberot and Taichi -->


<!-- Date: Mon May 7 21:13:17 2007 -->
tstsvt1 was plugged 
<p> 
Since test stand room was rearranged, the tstsvt1 was unplugged into power supply. So I plugged tstsvt1 into power supply. 
</p>
<!-- Author: Taichi -->


<!-- Date: Thu May 24 01:25:55 2007 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=svt&action=view&page=-387&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=svt&action=view&page=-387  width='300' align='top'></a></td><td>Beam position</td></tr></table>
<!-- Author: Benedetto -->
<!-- Comment: Thu May 24 01;29;41 comment by...Benedetto -->
<pre>Acnet page of the beam position:
page T73, #15 , subpage LOWBETA

The values to check are the green one (updated in real time).</pre>


<!-- Date: Sat Jun 9 07:02:41 2007 -->
<p>SVT TEST</p> 
<p> 
We did test for new svt firmware which detects BC mismatches between L1A and EE. But new configuration did not work correctly. b0svt09 got stuck during 'config' transition. We will investigate what was wrong and request test at low luminosity again.  
</p>
<!-- Author: Taichi -->


<!-- Date: Mon Jun 18 23:42:04 2007 -->
<pre>The 06/16 at 9.00 A.M. Guembong changed the beamfit code. 
The present code is the same that was used in svtmon v3_0. 
Since now the current svtmon version loaded on the crates is  V4_2,  
that is a merge of the V3_0 beamfit and V4_0 for all the others things. 
This code is working with no problems, see picture below.</pre>
<!-- Author: Benedetto -->


<!-- Date: Mon Jun 18 23:44:07 2007 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=svt&action=view&page=-388&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=svt&action=view&page=-388  width='300' align='top'></a></td><td>Beam position inthe last two stores</td></tr></table>
<!-- Author: Benedetto -->


<!-- Date: Tue Jun 19 00:04:30 2007 -->
<pre>Today i have tested the libraries and the consumer realized with S.L. 4.4 
1)Runs 243769 and 243772: Consumer (new version running on b0server00 and current version of libraries. 
2)run 243778 :  Consumer (new version running) on b0server00 and new  version of libraries in the crates. The new libraries are realized iin SL 4.4 and contains some change in the tree of the histograms. 
In all time the ACNET connection was good and updated (see plot below), good too histograms on HistodysplaMain, beamfit HTML pages, spydumps, crate status HTML pages. 
Still problems on histograms in ps format, Ajax browser , browsable histograms. </pre>
<!-- Author: Benedetto -->


<!-- Date: Tue Jun 19 00:06:06 2007 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=svt&action=view&page=-389&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=svt&action=view&page=-389  width='300' align='top'></a></td><td>Acnet plot of the beam position during the test on b0server00</td></tr></table>
<!-- Author: Benedetto -->


<!-- Date: Thu Jun 28 09:45:58 2007 -->
<pre>Hi, 
 
We're testing the SL4 readiness of the svtspymon system. 
In order to do that we must run a test version of the svt 
consumer at times. This will appear as SVTSPYMON_TEST 
on the consumer status page.  
 
Please tell the aces to let it run. 
 
Benedetto & Subir 
 
</pre>
<!-- Author: Subir Sarkar -->
<!-- Comment: Thu Jun 28 14;20;56 comment by...Subir Sarkar -->
<pre>The SL4 version of the updated SVT consumer is now happily running as SVTSPYMON_TEST. We've also pointed the Ajax browser to look at the Root file produced by the new consumer. This means, until we 
switch back to the production consumer - you will only be able to 
browse the so-called online histograms, but will not get a list
of all the runs.

You can access both the consumers using the HistoDisplayMain in the usual way. 
After we become confident about the new consumer we'll switch to
the directory structure for the histograms and install a compatible ajax browser.

- Benedetto & Subir

</pre>


<!-- Date: Mon Jul 2 16:16:20 2007 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=svt&action=view&page=-390&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=svt&action=view&page=-390  width='300' align='top'></a></td><td>Beam moved</td></tr></table>
<!-- Author: Benedetto -->


<!-- Date: Wed Jul 4 23:50:24 2007 -->
<pre>I updated the SVT pattern to follow the new beam position. 
I also update the SVTVME library to include recent minor changes (i.e. a few scripts moved into the library) 
</pre>
<!-- Author: Alberto -->


<!-- Date: Thu Jul 5 16:43:12 2007 -->
<pre>We installed new Ghostbuster on b0svt09 at June 26. 
This new Ghostbuster detects bunch counter mismatch between EE and L1A and send CDF ERROR to Run Controll to issue auto HRR. 
This new Ghostbuster is running from June 28 after long quiet time(there were two quenches) without no problem. 
If you want switch off to detect bunch counter mismatch, change parameter of gb_final_GB_CHECK_BC_EN 1 to 0 in hwset file.</pre>
<!-- Author: Taichi -->


<!-- Date: Fri Jul 6 14:27:53 2007 -->
<pre>I installed new firmware to two spare GB boards. 
These two spare GB boards are now in tstsvt1 in test stand room on 2nd floor.</pre>
<!-- Author: Taichi -->


<!-- Date: Sat Jul 14 13:53:15 2007 -->
<pre>We tested spare GB which is numebr 3 with fakehits. We leave this board in b0svt09 to take data. 
We took out GB 4 which is first one we used with new firmware. 
 </pre>
<!-- Author: Alberto, Stefano and Taichi -->


<!-- Date: Mon Jul 16 10:53:21 2007 -->
<pre>I took out GB 4 from SVT 09 and put in GB 5</pre>
<!-- Author: Stefano -->


<!-- Date: Wed Jul 18 10:44:47 2007 -->
<pre>&lt;h2&gt;I was paged&lt;/h2&gt; 
I got paged because during config SVT08 was having problem in findind the readout list. I did powercicle the crate. Actually next time it would be worth just resetting the CPU.</pre>
<!-- Author: Stefano -->


<!-- Date: Mon Jul 23 11:24:15 2007 -->
<table border=0><td><tr><td bgcolor=#e0e030><pre>We have plugged the TrackList output in place of the XTRP one in the input of SVT</pre></td></tr></td></table>
<!-- Author: Stefano -->


<!-- Date: Tue Jul 24 01:30:37 2007 -->
<table border=0><td><tr><td bgcolor=#e0e030><h3>Input to SVT from TrackList board</h3> 
Starting with run 245639 are taking data with SVT processing tracks coming from the TrackList board instead of the XTRP.</td></tr></td></table>
<!-- Author: Stefano Torre -->
<!-- Comment: Wed Oct 10 19;08;24 comment by...Alberto -->
<pre>It is worth nothing that while SVT is now getting XTRP tracks through the tracklist this is not true for the L2 that it is still receiving them from the XTRP.
This is the cause of some apparent SVT failures.
The reason being that XTRP it is sending diffent tracks to the L2 due to a small (1-2% level) bug in XTRP.
This problem will disappear when the Tracklist will also feed the L2.
So the current failures are apparent in the sense that both the SVT and the SVT simulation are doing the right thing.
However the current status is BAD because the SVT simulation cannot reproduce the actual SVT output since it is starting from the TL2D XTRP tracks which are different from those received by SVT.
This must be fixed asap, i.e. as soon as we get out of the shutdown!</pre>