[subexp-daq] Report of a possible bug of the CAEN_V560 module

[Håkan T Johansson]

Dear Günter,

just a side-note (since I'm not deep into r3bfuser...):

perhaps you already have, but if not, I suspect it would be good if you 
could push the versions of the code you are using (unless it is plain 
master branches).  Just to avoid some guesswork.

Cheers,
Håkan



On Thu, 22 Feb 2024, Hans Toshihide Törnqvist wrote:

> On 2024-02-22 10:04, Weber, Guenter Dr. wrote:
>> Dear friends,
>> 
>> after the bug in map_map was fixed, the freeze does not happen again. 
>> Very good!
>
> Thanks for testing, I'm saving that fix myself!
>
>> Now back to my original concern regarding the V560 module ...
>> 
>> readout_dt looks like this:
>> 
>> uint32_t
>> caen_v560_readout_dt(structCrate*a_crate, structModule*a_module)
>> {
>>      (void)a_crate;
>> LOGF(spam)(LOGL, NAME" readout_dt {");
>> a_module->event_counter.value++;
>> LOGF(spam)(LOGL, NAME" readout_dt(ctr=0x%08x) }",
>> a_module->event_counter.value);
>> return0;
>> }
>> 
>> The module counter is incremented by one every time readout_dt is 
>> executed. This results in a problem in crate.c:
>> 
>> 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);
>> 
>> create_do_shad=!crate_get_do_shadow(a_crate);
>> printf("%s: diff_module: %u, module_crate_counter: %u, 
>> module_event_counter: %u, module_this_minus_crate: %u\n", 
>> keyword_get_string(module->type), diff_module, 
>> (*module->crate_counter).value, (module->event_counter).value, 
>> module->this_minus_crate);
>> if(0==diff_module&&
>>                  ( create_do_shad||
>> NULL==module->props->readout_shadow||
>> 0==diff_shadow)) {
>> ok=1;
>> printf("%u\n", ok);
>> break;
>>              }
>> getchar();
>> 
>> When the difference between (*module->crate_counter).value and 
>> (module->event_counter).value is evaluated the later was already 
>> incremented as readout_dt for the module was already executed while the 
>> former counter was not incremented.
>
> The crate counter should have been incremented by the readout function 
> that calls 'crate_readout_dt'. If I remember correctly you used the 
> r3bfuser, so somewhere in fuser.c there's a function fuser_readout which 
> calls crate_tag_counter_increase. The crate counter increment is 
> "abstracted" away a bit, due to module tagging and multi-event support 
> when it can increase by an arbritary value between events.
>
>> This is the output:
>> 
>> CAEN_V560: diff_module: 4294967295, module_crate_counter: 0, 
>> module_event_counter: 1, module_this_minus_crate: 0
>> 
>> Note that diff_module shows the result of an "0 - 1" operation when 
>> working with unsigned integers.
>
> Looks like the crate counter stays still on 0 indeed. Do you have a 
> snippet of the drasi log around this error message?
>
>> The original version of the crate.c code would now again execute 
>> readout_dt of module V560, thus incrementing the module counter another 
>> time. Thus, diff_module would be "0 - 2". This would repeat until the 
>> timeout condition a bit later in the code is reached.
>> Then the modules would be re-initialized, thus setting 
>> (module->event_counter).value of V560 back to zero. But the crate 
>> counter would be incremented. Thus, by shear luck the next try of the 
>> same test would have (*module->crate_counter).value and 
>> (module->event_counter).value both equal to 1. And from this point the 
>> DAQ is running as intended.
>
> It sounds to me like the old version was very broken and should be 
> buried, deep.
>
> Best regards,
> Hans
>
>> Ok, I hope the explanation was clear and I understood correctly what is 
>> happening.
>> 
>> Best greetings
>> Günter
> -- 
> subexp-daq mailing list
> subexp-daq at lists.chalmers.se
> https://lists.chalmers.se/mailman/listinfo/subexp-daq
>