[subexp-daq] Question on COUNTER_DIFF in crate.c

[Håkan T Johansson]

Dear Günter,

I think Hans might have to correct me.

This is not exactly what this code does, but typically the modules have a 
trigger/event counter, which is incremented for each gate/common signal 
they receive on the front-panel.

When the readout is event-by-event, these counters are checked strictly by 
nurdlib, in order to detect cabling issues, double-triggers and so on. 
This is especially important for modules that have multi-event buffers, 
that otherwise easily can become desynchronised.  (It takes of course some 
time to read these counters, which contributes to the overall deadtime. 
But the amount of times this has 'saved' data-taking by detecting issues 
early make it very worthwhile.)


What the code you refer to is doing is I think 'abusing' this a bit. 
There is typically some time (order of us) between the trigger, and when 
the signals have been digitised and the data becomes available.  Often, 
those counters are only updated after that is the case.  To me it looks 
like this function use the counters (which we anyhow want to check) to 
wait for the modules to have finished converting one event.


Best regards,
Håkan





On Fri, 16 Feb 2024, Weber, Guenter Dr. wrote:

> 
> Dear friends,
> 
> 
> we are now trying to add a new module into NURDLIB. At the beginning, we just want to have a 'software version' of the module, so no
> hardware involved yet.
> 
> 
> We are stuck with the following code in crate.c (line 1262 and following):
> 
> 
>             diff_module = COUNTER_DIFF(*module->crate_counter,
>                 module->event_counter, module->this_minus_crate);
>             /* TODO: Clean this. */
>             shadow_counter.value =
>                 module->shadow.data_counter_value;
>             shadow_counter.mask = module->event_counter.mask;
>             diff_shadow = COUNTER_DIFF(*module->crate_counter,
>                 shadow_counter, module->this_minus_crate);
> 
> 
> As we understand, the idea here is to check with a call of readout_dt if the module's internal counter agrees with the counter of the
> crate for the given module. Basicly when the crate thinks it has accessed the module n times, the module should report the same number of
> access attempts. Is this understanding correct?
> 
> 
> If yes, how exactly should the module increment it's internal counter? If this is done on readout_dt, a mismatch between the crate and the
> internal counter occurs as soon as we stop the aquisition.
> 
> 
> I can explain in more details, but maybe first you can explain to us what the whole idea behind this check is? To us it looks like also
> the dummy module implementation will have problems with it.
> 
> 
> 
> 
> Thank you very much!
> 
> 
> 
> 
> Best greetings
> 
> Günter
> 
> 
> 
>