[subexp-daq] Strange instability of the event counter register of the CAEN V767 module
Hans Toshihide Törnqvist
hans.tornqvist at chalmers.se
Tue Mar 5 17:38:20 CET 2024
Dear Günter,
We had a look, was overall good! I added a few things in order to be
able to test the software part, it's now in the 'master' branch. Please
test to make sure that I didn't add "unforeseen features" :)
Once this has been tested I have additional and larger updates, mainly
to keep the re-init behaviour and some coding patterns in line with
other modules (to let the crate re-init on failures and report proper
error codes, having time-outs for potentially infinite loops etc).
Best regards,
Hans
On 2024-03-04 17:08, Weber, Guenter Dr. wrote:
> Dear friends,
>
>
> we just pushed a new branch to the NURDLIB repository which now contains
> the module CAEN V767A. Please have a look at our implementation, wether
> this makes sense to you or not. At the moment, the operation mode of the
> module is hard coded, but this can be changed easily.
>
>
>
>
> Best greetings
>
> Günter
>
>
>
> ------------------------------------------------------------------------
> *Von:* subexp-daq <subexp-daq-bounces at lists.chalmers.se> im Auftrag von
> Weber, Guenter Dr. <g.weber at hi-jena.gsi.de>
> *Gesendet:* Freitag, 1. März 2024 19:28:36
> *An:* Discuss use of Nurdlib, TRLO II, drasi and UCESB.
> *Betreff:* Re: [subexp-daq] Strange instability of the event counter
> register of the CAEN V767 module
> Dear Hans,
>
> indeed, this modification of the event counter register only happens in
> the init routines. However, part of init is clearing the module and also
> setting the event counter to zero. If one does this right after the
> commands that somehow 'touch' the event counter value, it is possible
> that after clearing the event counter the zero value is then overwritten.
>
> Thus, it is necessary to organize init like this:
>
> 1) Doing all the settings.
> 2) Waiting an approbiate amount of time.
> 3) Clearing the module, setting counter to zero.
>
> We now also learned that at least one command sets the counter register
> permanently to 1. Thus, it is not possible to execute this command
> 'on-the-fly' and still have a consistent value of the event counter
> afterwards. This means the counter comparision in crate.c will no longer
> work. Instead one needs a complete restart. (But as I understand, the
> fast init is meant to be executed also without a complete restart of
> everything, right?)
>
> If I understood the manual correct, there is the possibility to send a
> software trigger. With this it might be possible to readout the current
> event counter, do the programming commands, then clear the module, set
> counter to zero and now send software triggers to increment the counter
> value to the original value.
>
> Ok, I hope thise explanation/though process is understandable.
>
>
>
> Best greetings and have a nice weekend
> Günter
>
>
>
>
>
>
> ------------------------------------------------------------------------
> *Von:* Hans Toshihide Törnqvist <hans.tornqvist at chalmers.se>
> *Gesendet:* Freitag, 1. März 2024 18:27:59
> *An:* Discuss use of Nurdlib, TRLO II, drasi and UCESB.; Weber, Guenter Dr.
> *Betreff:* Re: [subexp-daq] Strange instability of the event counter
> register of the CAEN V767 module
> Dear Günter,
>
> It looks to me like this happens when configuring the module, i.e.
> setting windows, operating mode etc? And not in the "inner" readout loop?
>
> From the manual, it seems like one has to wait 2 seconds (oof) after
> the soft-reset, and do polling of the the micro-controller
> communication. An additional sleep of 100 ms after the complete setup
> seems fine.
>
> Some Caen and Mesytec implementations already sleep in many places
> during initialization, and the v1n90 modules also have the TDC
> micro-controller support.
>
> A small schematic for an idea what registers are touched in the modules:
>
> init {
> init_slow {
> mapping, one-time settings
> }
> init_fast {
> all other settings
> sleep to let the module settle
> }
> (post_init optional)
> }
> loop {
> readout_dt {
> read module counter, typically a 32-bit reg-read
> if available, read buffer size, another 16/32-bit reg-read
> }
> (release dt optional)
> readout {
> read buffer {
> either a loop with 32-bit reg-reads from event-fifo,
> or block transfer
> }
> }
> }
>
> So during the readout loop the tests you made should not be a concern,
> if I understood it correctly?
>
> Two requests:
>
> - Could you make the 2 seconds soft-reset sleep a config with the
> default value 2 s? Software tests can then set it to 0 s.
>
> - I'm guessing it's sufficient to wait for ~100 ms at the end of
> init_fast for the internals to be ready, please make also this configurable.
>
> Since an increasing event-counter relies on external triggers, I don't
> see how it could be used while setting up the DAQ before running, a
> "time_sleep(0.1);" or a bit longer ought to work.
>
> Happy weekend,
> Hans
>
> On 2024-03-01 16:16, Weber, Guenter Dr. wrote:
>> Dear friends,
>>
>>
>> we just noticed that the value that is read from the event counter
>> register (Base + %004C) of V767 is not stable during times when the
>> module does internal operations. To demonstrate this we used the
>> following code:
>>
>>
>> last_event_counter = MAP_READ(caen_v767a->sicy_map, event_counter);
>> write_op(caen_v767a->sicy_map, 0x1000); /* set mode of operation */
>> t = time_getd();
>> while ( last_event_counter != MAP_READ(caen_v767a->sicy_map,
>> event_counter) )
>> {
>> usleep(1);
>> }
>> t = time_getd() - t;
>> LOGF(info)(LOGL, NAME" TIME is %f", t);
>>
>> last_event_counter = MAP_READ(caen_v767a->sicy_map, event_counter);
>> window_setting = config_get_int32(caen_v767a->module.config, KW_WIDTH,
>> CONFIG_UNIT_NONE, 0x0001, 0x84D0);
>> write_op(caen_v767a->sicy_map, 0x3000); /* set time window length */
>> write_op(caen_v767a->sicy_map, window_setting);
>> t = time_getd();
>> while ( last_event_counter != MAP_READ(caen_v767a->sicy_map,
>> event_counter) )
>> {
>> usleep(1);
>> }
>> t = time_getd() - t;
>> LOGF(info)(LOGL, NAME" TIME is %f", t);
>>
>> last_event_counter = MAP_READ(caen_v767a->sicy_map, event_counter);
>> window_setting = config_get_int32(caen_v767a->module.config, KW_OFFSET,
>> CONFIG_UNIT_NONE, 1 - 320000, window_setting + 2000 - 1);
>> write_op(caen_v767a->sicy_map, 0x3200); /* set time window offset */
>> write_op(caen_v767a->sicy_map, window_setting);
>> t = time_getd();
>> while ( last_event_counter != MAP_READ(caen_v767a->sicy_map,
>> event_counter) )
>> {
>> usleep(1);
>> }
>> t = time_getd() - t;
>> LOGF(info)(LOGL, NAME" TIME is %f", t);
>>
>> last_event_counter = MAP_READ(caen_v767a->sicy_map, event_counter);
>> write_op(caen_v767a->sicy_map, 0x7000); /* set data ready status to
>> event ready */
>> t = time_getd();
>> while ( last_event_counter != MAP_READ(caen_v767a->sicy_map,
>> event_counter) )
>> {
>> usleep(1);
>> }
>> t = time_getd() - t;
>> LOGF(info)(LOGL, NAME" TIME is %f", t);
>>
>> And the output in two trials was the following:
>>
>>
>> 10: module/caen_v767a/caen_v767a.c:143: ..CEAN_V767A TIME is 0.000002
>> 10: module/caen_v767a/caen_v767a.c:155: ..CEAN_V767A TIME is 0.000002
>> 10: module/caen_v767a/caen_v767a.c:167: ..CEAN_V767A TIME is 0.055224
>> 10: module/caen_v767a/caen_v767a.c:177: ..CEAN_V767A TIME is 0.000354
>>
>> 10: module/caen_v767a/caen_v767a.c:143: ....CEAN_V767A TIME is 0.000002
>> 10: module/caen_v767a/caen_v767a.c:155: ....CEAN_V767A TIME is 0.000002
>> 10: module/caen_v767a/caen_v767a.c:167: ....CEAN_V767A TIME is 0.055223
>> 10: module/caen_v767a/caen_v767a.c:177: ....CEAN_V767A TIME is 0.000387
>>
>> Thus, we can conclude that the event counter register is set to some
>> fake value for up to almost 60 ms as a result of an internal operation
>> of the module. Only after this time, the register goes back to the real
>> value.
>>
>>
>> We will now take care of this effect and after each WRITE_OP call wait
>> for the event counter to to gack to the original value. However, who
>> knows what happens in the other registers of the module (and for how long).
>>
>>
>> As the event counter value is used as a sanity check in CRATE.C it might
>> make sense to check if some of the other CAEN modules also exhibit this
>> 'fascinating feature'.
>>
>>
>>
>>
>>
>> Best greetings
>>
>> Günter
>>
>>
>>
>>
>
More information about the subexp-daq
mailing list