<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
<meta name="Generator" content="Microsoft Exchange Server">
<!-- converted from text --><style><!-- .EmailQuote { margin-left: 1pt; padding-left: 4pt; border-left: #800000 2px solid; } --></style>
</head>
<body>
<style type="text/css" style="display:none;"><!-- P {margin-top:0;margin-bottom:0;} --></style>
<div id="divtagdefaultwrapper" style="font-size:14pt;color:#000000;font-family:Calibri,Helvetica,sans-serif;" dir="ltr">
<p>Dear friends,</p>
<p><br>
</p>
<p>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.</p>
<p><br>
</p>
<p><br>
</p>
<p><br>
</p>
<p>Best greetings</p>
<p>Günter<br>
</p>
<p><br>
</p>
<p><br>
</p>
</div>
<hr style="display:inline-block;width:98%" tabindex="-1">
<div id="divRplyFwdMsg" dir="ltr"><font face="Calibri, sans-serif" style="font-size:11pt" color="#000000"><b>Von:</b> subexp-daq <subexp-daq-bounces@lists.chalmers.se> im Auftrag von Weber, Guenter Dr. <g.weber@hi-jena.gsi.de><br>
<b>Gesendet:</b> Freitag, 1. März 2024 19:28:36<br>
<b>An:</b> Discuss use of Nurdlib, TRLO II, drasi and UCESB.<br>
<b>Betreff:</b> Re: [subexp-daq] Strange instability of the event counter register of the CAEN V767 module</font>
<div> </div>
</div>
<div>
<div>Dear Hans,<br>
<br>
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.<br>
<br>
Thus, it is necessary to organize init like this:<br>
<br>
1) Doing all the settings.<br>
2) Waiting an approbiate amount of time.<br>
3) Clearing the module, setting counter to zero.<br>
<br>
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?)<br>
<br>
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.<br>
<br>
Ok, I hope thise explanation/though process is understandable.<br>
<br>
<br>
<br>
Best greetings and have a nice weekend<br>
Günter <br>
<br>
<br>
<br>
<br>
<br>
<br>
<hr tabindex="-1" style="display:inline-block; width:98%">
<div id="x_divRplyFwdMsg" dir="ltr"><font face="Calibri, sans-serif" color="#000000" style="font-size:11pt"><b>Von:</b> Hans Toshihide Törnqvist <hans.tornqvist@chalmers.se><br>
<b>Gesendet:</b> Freitag, 1. März 2024 18:27:59<br>
<b>An:</b> Discuss use of Nurdlib, TRLO II, drasi and UCESB.; Weber, Guenter Dr.<br>
<b>Betreff:</b> Re: [subexp-daq] Strange instability of the event counter register of the CAEN V767 module</font>
<div> </div>
</div>
</div>
<font size="2"><span style="font-size:10pt;">
<div class="PlainText">Dear Günter,<br>
<br>
It looks to me like this happens when configuring the module, i.e. <br>
setting windows, operating mode etc? And not in the "inner" readout loop?<br>
<br>
From the manual, it seems like one has to wait 2 seconds (oof) after <br>
the soft-reset, and do polling of the the micro-controller <br>
communication. An additional sleep of 100 ms after the complete setup <br>
seems fine.<br>
<br>
Some Caen and Mesytec implementations already sleep in many places <br>
during initialization, and the v1n90 modules also have the TDC <br>
micro-controller support.<br>
<br>
A small schematic for an idea what registers are touched in the modules:<br>
<br>
init {<br>
init_slow {<br>
mapping, one-time settings<br>
}<br>
init_fast {<br>
all other settings<br>
sleep to let the module settle<br>
}<br>
(post_init optional)<br>
}<br>
loop {<br>
readout_dt {<br>
read module counter, typically a 32-bit reg-read<br>
if available, read buffer size, another 16/32-bit reg-read<br>
}<br>
(release dt optional)<br>
readout {<br>
read buffer {<br>
either a loop with 32-bit reg-reads from event-fifo,<br>
or block transfer<br>
}<br>
}<br>
}<br>
<br>
So during the readout loop the tests you made should not be a concern, <br>
if I understood it correctly?<br>
<br>
Two requests:<br>
<br>
- Could you make the 2 seconds soft-reset sleep a config with the <br>
default value 2 s? Software tests can then set it to 0 s.<br>
<br>
- I'm guessing it's sufficient to wait for ~100 ms at the end of <br>
init_fast for the internals to be ready, please make also this configurable.<br>
<br>
Since an increasing event-counter relies on external triggers, I don't <br>
see how it could be used while setting up the DAQ before running, a <br>
"time_sleep(0.1);" or a bit longer ought to work.<br>
<br>
Happy weekend,<br>
Hans<br>
<br>
On 2024-03-01 16:16, Weber, Guenter Dr. wrote:<br>
> Dear friends,<br>
> <br>
> <br>
> we just noticed that the value that is read from the event counter <br>
> register (Base + %004C) of V767 is not stable during times when the <br>
> module does internal operations. To demonstrate this we used the <br>
> following code:<br>
> <br>
> <br>
> last_event_counter = MAP_READ(caen_v767a->sicy_map, event_counter);<br>
> write_op(caen_v767a->sicy_map, 0x1000); /* set mode of operation */<br>
> t = time_getd();<br>
> while ( last_event_counter != MAP_READ(caen_v767a->sicy_map, <br>
> event_counter) )<br>
> {<br>
> usleep(1);<br>
> }<br>
> t = time_getd() - t;<br>
> LOGF(info)(LOGL, NAME" TIME is %f", t);<br>
> <br>
> last_event_counter = MAP_READ(caen_v767a->sicy_map, event_counter);<br>
> window_setting = config_get_int32(caen_v767a->module.config, KW_WIDTH, <br>
> CONFIG_UNIT_NONE, 0x0001, 0x84D0);<br>
> write_op(caen_v767a->sicy_map, 0x3000); /* set time window length */<br>
> write_op(caen_v767a->sicy_map, window_setting);<br>
> t = time_getd();<br>
> while ( last_event_counter != MAP_READ(caen_v767a->sicy_map, <br>
> event_counter) )<br>
> {<br>
> usleep(1);<br>
> }<br>
> t = time_getd() - t;<br>
> LOGF(info)(LOGL, NAME" TIME is %f", t);<br>
> <br>
> last_event_counter = MAP_READ(caen_v767a->sicy_map, event_counter);<br>
> window_setting = config_get_int32(caen_v767a->module.config, KW_OFFSET, <br>
> CONFIG_UNIT_NONE, 1 - 320000, window_setting + 2000 - 1);<br>
> write_op(caen_v767a->sicy_map, 0x3200); /* set time window offset */<br>
> write_op(caen_v767a->sicy_map, window_setting);<br>
> t = time_getd();<br>
> while ( last_event_counter != MAP_READ(caen_v767a->sicy_map, <br>
> event_counter) )<br>
> {<br>
> usleep(1);<br>
> }<br>
> t = time_getd() - t;<br>
> LOGF(info)(LOGL, NAME" TIME is %f", t);<br>
> <br>
> last_event_counter = MAP_READ(caen_v767a->sicy_map, event_counter);<br>
> write_op(caen_v767a->sicy_map, 0x7000); /* set data ready status to <br>
> event ready */<br>
> t = time_getd();<br>
> while ( last_event_counter != MAP_READ(caen_v767a->sicy_map, <br>
> event_counter) )<br>
> {<br>
> usleep(1);<br>
> }<br>
> t = time_getd() - t;<br>
> LOGF(info)(LOGL, NAME" TIME is %f", t);<br>
> <br>
> And the output in two trials was the following:<br>
> <br>
> <br>
> 10: module/caen_v767a/caen_v767a.c:143: ..CEAN_V767A TIME is 0.000002<br>
> 10: module/caen_v767a/caen_v767a.c:155: ..CEAN_V767A TIME is 0.000002<br>
> 10: module/caen_v767a/caen_v767a.c:167: ..CEAN_V767A TIME is 0.055224<br>
> 10: module/caen_v767a/caen_v767a.c:177: ..CEAN_V767A TIME is 0.000354<br>
> <br>
> 10: module/caen_v767a/caen_v767a.c:143: ....CEAN_V767A TIME is 0.000002<br>
> 10: module/caen_v767a/caen_v767a.c:155: ....CEAN_V767A TIME is 0.000002<br>
> 10: module/caen_v767a/caen_v767a.c:167: ....CEAN_V767A TIME is 0.055223<br>
> 10: module/caen_v767a/caen_v767a.c:177: ....CEAN_V767A TIME is 0.000387<br>
> <br>
> Thus, we can conclude that the event counter register is set to some <br>
> fake value for up to almost 60 ms as a result of an internal operation <br>
> of the module. Only after this time, the register goes back to the real <br>
> value.<br>
> <br>
> <br>
> We will now take care of this effect and after each WRITE_OP call wait <br>
> for the event counter to to gack to the original value. However, who <br>
> knows what happens in the other registers of the module (and for how long).<br>
> <br>
> <br>
> As the event counter value is used as a sanity check in CRATE.C it might <br>
> make sense to check if some of the other CAEN modules also exhibit this <br>
> 'fascinating feature'.<br>
> <br>
> <br>
> <br>
> <br>
> <br>
> Best greetings<br>
> <br>
> Günter<br>
> <br>
> <br>
> <br>
> <br>
</div>
</span></font></div>
</body>
</html>