[subexp-daq] Strange instability of the event counter register of the CAEN V767 module

[Weber, Guenter Dr.]

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
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.chalmers.se/pipermail/subexp-daq/attachments/20240304/4c8e8dc9/attachment.html>