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

[Hans Toshihide Törnqvist]

Dear all,

Everything looks fine, but I thought I could add a few more points, 
which were written in parallel to Håkan's reply, I'll try to update my 
text properly :)

---
The crate struct keeps a counter for every permutation of module tags. 
The counters are modified either by:

-) 'crate_tag_counter_increase' which should be called by the user code 
(e.g. the f-user) for every tag that should fire for a particular event, or

-) a scaler channel which counts the number of events, e.g. MASTER_START 
in a TRLO II vulom, or a v830 which has an accepted trigger cabled to an 
input, which is fully specified in main.cfg.

The latter overrides the former if configured, so the nurdlib f-user and 
r3bfuser always call 'crate_tag_counter_increase' per readout. For 
multi-event readout one would need to setup the latter approach. 
(Putting a description of this on the docu todo, if it's not already in...)

---
Best is when the "hardware" increments. For example, a v775 counts the 
number of signals sent on its trigger input, and nurdlib reads this 
value in readout_dt, which the crate then uses to compare with its 
software counters.
Some modules do not provide such counters directly before payload 
readout (e.g. gsi_tamex and similar) in which case the counting is done 
in software, which is mostly a test of the library logic. The module 
payload can carry a counter and trigger number however, which are 
checked later in '*parse_data'.

---
I will have a look at the dummy module, I thought we have a test with a 
few software triggers for it, otherwise I will add that.

Best regards,
Hans

On 2024-02-16 13:25, Håkan T Johansson wrote:
> 
> 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
>>
>>
>>
>>
>