<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>
<meta content="text/html; charset=UTF-8">
<style type="text/css" style="">
<!--
p
{margin-top:0;
margin-bottom:0}
-->
</style>
<div dir="ltr">
<div id="x_divtagdefaultwrapper" dir="ltr" style="font-size:14pt; color:#000000; font-family:Calibri,Helvetica,sans-serif">
<p>Dear friends,</p>
<p><br>
</p>
<p>I just pushed a fixed version of the CAEN V1n90 to Gitlab.</p>
<p><br>
</p>
<p>Please note that in the parser I had to comment out a check if the number of TDC words in the TDC trailer is equal to the number of words corresponding to this TDC that were actually read by the parser. Otherwise the automatic testing during NURDLIB compilation
fails. Thus, to implement this check, the test data needs to be reworked to actually match the structure of the data from the real module. See around page 70 in the manual of the V1190 module.</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>
<br>
</div>
<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> subexp-daq <subexp-daq-bounces@lists.chalmers.se> im Auftrag von Hċkan T Johansson <f96hajo@chalmers.se><br>
<b>Gesendet:</b> Dienstag, 16. April 2024 16:52:55<br>
<b>An:</b> Discuss use of Nurdlib, TRLO II, drasi and UCESB.<br>
<b>Betreff:</b> Re: [subexp-daq] NURDLIB - Problem in parser of caen_v1n90</font>
<div> </div>
</div>
</div>
<font size="2"><span style="font-size:10pt;">
<div class="PlainText"><br>
Dear Günter,<br>
<br>
if you are able to push to the master branch, we actually have a <br>
configuration problem. But also we do not push to the (remote) master <br>
branch of each other's projects.<br>
<br>
But in any case, please do not.<br>
<br>
It is easy to push to a branch with another name:<br>
<br>
git push <remote> <local-branch>:<remote-branch><br>
<br>
e.g.<br>
<br>
git push origin master:fixes-of-something<br>
<br>
...<br>
<br>
Or you can just creat a new local branch name first<br>
<br>
git branch <new-name><br>
git checkout <new-name><br>
<br>
and the do a<br>
<br>
git push origin <new-name><br>
<br>
Cheers,<br>
Hċkan<br>
<br>
<br>
On Tue, 16 Apr 2024, Weber, Guenter Dr. wrote:<br>
<br>
> <br>
> Dear friends,<br>
> <br>
> <br>
> we have (most probably fixed) the issue by modifying the parser a bit. See<br>
> attachment.<br>
> <br>
> <br>
> Unfortunately, before doing the changes, I did not open a new branch. Am I<br>
> allowed to commit our changes to the master branch? Or do you want to<br>
> implement the new parser (if you think it is fine this way)?<br>
> <br>
> <br>
> <br>
> <br>
> Best greetings<br>
> <br>
> Günter<br>
> <br>
> ____________________________________________________________________________<br>
> Von: Weber, Guenter Dr.<br>
> Gesendet: Dienstag, 16. April 2024 07:11:32<br>
> An: Discuss use of Nurdlib, TRLO II, drasi and UCESB.<br>
> Betreff: NURDLIB - Problem in parser of caen_v1n90 <br>
> <br>
> Dear friends,<br>
> <br>
> <br>
> yesterday I managed to get the DAQ starting (using the updated software and<br>
> howto instructions). However, the readout of the TDC module V1190A failed:<br>
> <br>
> <br>
> 2024-04-15 14:29:36.979260 i RIO4L-2/MAIN crate_init(POLARIMETER) }<br>
> +0200 CEST :f_user.c:1257:<br>
> 2024-04-15 14:29:36.979280 E RIO4L-2/MAIN had readout error, ret=0x2,<br>
> trigger=1, prev=1<br>
> +0200 CEST :module/caen_v1n90/caen_v1n90.c:651:<br>
> 2024-04-15 14:29:36.979684 E RIO4L-2/MAIN Trailer corrupt<br>
> (ofs=0x00000010,u8[4]=0x0900032f).<br>
> +0200 CEST :crate/crate.c:2074:<br>
> 2024-04-15 14:29:36.979712 E RIO4L-2/MAIN POLARIMETER[3]=CAEN_V1190<br>
> parse error=0x00000002, dumping data:<br>
> +0200 CEST :crate/crate.c:2083:<br>
> 2024-04-15 14:29:36.979724 i RIO4L-2/MAIN ---[ Dump begin ]---<br>
> +0200 CEST :crate/crate.c:2083:<br>
> 2024-04-15 14:29:36.979734 i RIO4L-2/MAIN Start=0x3005ef08 <br>
> Bytes=44=0x2c<br>
> +0200 CEST :crate/crate.c:2083:<br>
> 2024-04-15 14:29:36.979755 i RIO4L-2/MAIN 0: 40000003 0800032f<br>
> 00702106 18000003 0900032f 19000002 0a00032f 1a000002<br>
> +0200 CEST :crate/crate.c:2083:<br>
> 2024-04-15 14:29:36.979770 i RIO4L-2/MAIN 20: 0b00032f 1b000002<br>
> 80000163<br>
> +0200 CEST :crate/crate.c:2083:<br>
> 2024-04-15 14:29:36.979780 i RIO4L-2/MAIN ---[ Dump end ]---<br>
> +0200 CEST :crate/crate.c:1554:<br>
> 2024-04-15 14:29:36.979810 E RIO4L-2/MAIN POLARIMETER: readout failed!<br>
> +0200 CEST :crate/crate.c:1598:<br>
> 2024-04-15 14:29:36.979823 E RIO4L-2/MAIN POLARIMETER: had problems,<br>
> re-initializing.<br>
> <br>
> <br>
> To us it looks like the parser does not account for the fact that the module<br>
> contains several individual TDC units which each will produce a TDC header<br>
> plus payload. And only after all TDC units were readout, finally the trailer<br>
> will appear.<br>
> <br>
> <br>
> (As I can see, the 1n90 series ranges from 16 channels to 128 channels with<br>
> the high channel number modules having several individual TDC units. Maybe,<br>
> this whole issue was overlooked when writing the parser code?)<br>
> <br>
> <br>
> In the attachment, I send a modified version of the parser where for testing<br>
> purposes it is assumed that the module has four TDC units (as should be the<br>
> case for our module). Compilation of this code works, but it fails in the<br>
> unit test with the following errors:<br>
> <br>
> <br>
> make: Warning: File<br>
> `build_cc_ppc-linux_4.2.2_debug/module/caen_v1n90/caen_v1n90.d' has<br>
> modification time 45 s in the future<br>
> CC build_cc_ppc-linux_4.2.2_debug/module/caen_v1n90/caen_v1n90.o<br>
> LD build_cc_ppc-linux_4.2.2_debug/test<br>
> TEST build_cc_ppc-linux_4.2.2_debug/test_ok<br>
> [tests/argmatch.c:127: Shorts]<br>
> [tests/argmatch.c:128: Longs]<br>
> [tests/argmatch.c:129: Combos]<br>
> [tests/argmatch.c:130: ShortsWithValues]<br>
> [tests/argmatch.c:131: LongsWithValues]<br>
> [tests/argmatch.c:132: MissingValue]<br>
> [tests/base.c:110: MemoryCheck]<br>
> [tests/base.c:111: EventBufferAdvance]<br>
> 2024-04-15,20:11:37:ERRR: Invalid pointer to advance event buffer.<br>
> [tests/base.c:47]<br>
> 2024-04-15,20:11:37:ERRR: Calling abort()... [tests/base.c:47]<br>
> 2024-04-15,20:11:37:ERRR: Invalid pointer to advance event buffer.<br>
> [tests/base.c:56]<br>
> 2024-04-15,20:11:37:ERRR: Calling abort()... [tests/base.c:56]<br>
> 2024-04-15,20:11:37:ERRR: Tried to advance outside event buffer.<br>
> [tests/base.c:72]<br>
> 2024-04-15,20:11:37:ERRR: Calling abort()... [tests/base.c:72]<br>
> [tests/base.c:112: EventBufferInvariant]<br>
> 2024-04-15,20:11:37:ERRR: Event-buffer inconsistent (0x103ae008:11 !=<br>
> 0x103ae008:10). [tests/base.c:87]<br>
> 2024-04-15,20:11:37:ERRR: Calling abort()... [tests/base.c:87]<br>
> 2024-04-15,20:11:37:ERRR: Event-buffer inconsistent (0x103ae008:9 !=<br>
> 0x103ae008:10). [tests/base.c:91]<br>
> 2024-04-15,20:11:37:ERRR: Calling abort()... [tests/base.c:91]<br>
> 2024-04-15,20:11:37:ERRR: Event-buffer inconsistent (0x103ae009:10 !=<br>
> 0x103ae008:10). [tests/base.c:95]<br>
> 2024-04-15,20:11:37:ERRR: Calling abort()... [tests/base.c:95]<br>
> 2024-04-15,20:11:37:ERRR: Event-buffer inconsistent (0x103ae007:10 !=<br>
> 0x103ae008:10). [tests/base.c:99]<br>
> 2024-04-15,20:11:37:ERRR: Calling abort()... [tests/base.c:99]<br>
> <br>
> For comparison, I also send the parser from the NURDLIB version that Bastian<br>
> had set up for us.<br>
> <br>
> <br>
> <br>
> It would be really great if you could have a look into this. Most probably<br>
> this is the last issue that we are facing, before the DAQ is fine again.<br>
> <br>
> <br>
> <br>
> <br>
> Thank you very much!<br>
> <br>
> <br>
> <br>
> Best greetings<br>
> <br>
> Günter<br>
> <br>
> <br>
> <br>
> <br>
> <br>
> <br>
> <br>
></div>
</span></font>
</body>
</html>