Yes- I can confirm that this is what happens, although I assume you
DAQ people understand better where the error trapping happens.
> But in any case I want to stress that even if the buffer could be perhaps put
> formally in a correct way the data are in any case wrong because part of the
> equipment is missing.
> In the future we could study the possibility of a better VME error
> handling; but this could be difficult due to the VME protocol and
> the WFD itself (there is no "standard" way to test a module response,
> like for example the q for Camac)
Also true. However, it would be very helpful to have some better handle
on what is happening. For example, the DAQ could at least print out
the CAMAC-list line being executed during the error. This would have been
a big help last month. We typically had to find the source of these
errors by cutting up the CAMAClist. The errors were typically a bug in
external control logic that did not STOP the WFD.
> In conclusion for the current run I think that the only solution is
> to make Dream robust enough to recovery such errors.
> Francesco
Probably also true. The men at LNGS (Chris,Chris,Nat) have done a great
job knocking the error rate down to a few per run. But our nagging worry
is that the errors will preferentially occur during interesting events
and we will be biased against them. We can test this as much as possible
by flashing LED's to look like monopoles, for example, but is never
really the same thing. Anything that can be done to make the error
trapping more robust would be greatly appreciated.
Ed