OK I figured out that the problem I mentioned in my last message(some
events which seem to have data in the WFDs 2.5 usecs to early) happens
whenever the data comes from SM 4. First of all here is a pretty
normal event from SM6.
------------------------------------------------------------------------
DASH++> ana good=1
Run 10748; Event 7
Time Node v0
UT Time: 95/8/21 11:35:55:5077806
VAX Time: 95/8/21 12:35:46:97
Trigger Node v0
E BE CL S FCH
R AR II T MSI
P RP TP M TPP
u IG MT
---------------- uVAX#1
---------------- uVAX#2
-*-*---*-*--*--- uVAX#3
F CCC EEGGFC LL
M IIS RRCCMS AE
T TTP PP TP SD
34 3434XX
---------------- uVAX#1
---------------- uVAX#2
----*--*-------- uVAX#3
VME Addr: 6270000( 1319 dec) 128 buckets Maxtime: 1000455
VME Addr: 6260000( 1318 dec) 192 buckets Maxtime: 1000480
VME Addr: 60b0000( 1291 dec) 176 buckets Maxtime: 1000440
VME Addr: 60a0000( 1290 dec) 112 buckets Maxtime: 1000430
VME Addr: 6010000( 1281 dec) 252 buckets Maxtime: 1000440
VME Addr: 6000000( 1280 dec) 128 buckets Maxtime: 1000390
DASH++>
------------------------------------------------------------------------
OK so in this event there was a ERP, BARI, LIP, CSPAM and STM trigger.
All of these triggers except the STM trigger are plugged into the STOP
master. Now the CSPAM is the fastest trigger so we should expect that
it caused the stop and the data should be some hundreds of nanoseconds
before the trigger + 1ms. Above you can see that the MaxTime(the time
of the largest ADC sample) is indeed about 400 ns before the trigger
in all of the channels. In addition just so everything holds together
here is the STOP master information:
------------------------------------------------------------------------
DASH++> call event stop
Stop Master Node version:1
===================================================================
Trig | Relative Trig Time in 100s-nanoseconds |
| SM1 | SM2 | SM3 | SM4 | SM5 | SM6 |
===================================================================
ERP | 0 | 0 | 0 | 0 | 10000 | 11 |
LIP | 0 | 0 | 0 | 0 | 10000 | 66 |
SMT | 0 | 0 | 0 | 0 | 10000 | 10000 |
STM | 0 | 0 | 0 | 0 | 10000 | 10000 |
FMT | 0 | 0 | 0 | 0 | 10000 | 10000 |
HIP | 0 | 0 | 0 | 0 | 10000 | 10000 |
CSPAM | 0 | 0 | 0 | 0 | 0 | 0 |
ISTOP | 0 | 0 | 0 | 0 | 10000 | 10000 |
------------------------------------------------------------------------
So as I said the CSPAM on SM6 showed up first(registering 0 in the
module) followed 1.1 usecs later by the ERP and by 6.6 usecs later by
the LIP.
So everything is just as we expect. Now lets look at an event from
SM4:
------------------------------------------------------------------------
DASH++> ana good=1
Run 10748; Event 87
Time Node v0
UT Time: 95/8/21 11:38:30:5487515
VAX Time: 95/8/21 12:38:22:23
Trigger Node v0
E BE CL S FCH
R AR II T MSI
P RP TP M TPP
u IG MT
---------------- uVAX#1
-*-*---*-*--*--- uVAX#2
---------------- uVAX#3
F CCC EEGGFC LL
M IIS RRCCMS AE
T TTP PP TP SD
34 3434XX
---------------- uVAX#1
----*--*-----*-- uVAX#2
---------------- uVAX#3
VME Addr: 4250000( 805 dec) 116 buckets Maxtime: 1002385
VME Addr: 4240000( 804 dec) 124 buckets Maxtime: 1002355
VME Addr: 4210000( 801 dec) 124 buckets Maxtime: 1002355
VME Addr: 4200000( 800 dec) 144 buckets Maxtime: 1002375
VME Addr: 40d0000( 781 dec) 136 buckets Maxtime: 1002350
VME Addr: 40c0000( 780 dec) 184 buckets Maxtime: 1002350
VME Addr: 4070000( 775 dec) 228 buckets Maxtime: 1002320
VME Addr: 4060000( 774 dec) 428 buckets Maxtime: 1002350
DASH++>
------------------------------------------------------------------------
So this event is just like the last event *except* that the data is
about 2.3 usec before the CSPAM trigger registered in the stop
master.(The stop master data looks the same.)
So apparently there is an extra *delay* on SM4. Eric should try to
measure the difference between CSPAM trigger arrival and STOP arrival on
SM4. I'm not sure where the delay would be. I suppose another(much less
likely) probability is that the WFD clock on SM4 is too fast so it
looks like more time has gone by then really happened.
-Chris