[subexp-daq] NURDLIB - Problem in parser of caen_v1n90

Wed Apr 17 14:49:40 CEST 2024

Dear friends,

I just pushed a fixed version of the CAEN V1n90 to Gitlab.

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.

Best greetings

Günter

________________________________
Von: subexp-daq <subexp-daq-bounces at lists.chalmers.se> im Auftrag von Håkan T Johansson <f96hajo at chalmers.se>
Gesendet: Dienstag, 16. April 2024 16:52:55
An: Discuss use of Nurdlib, TRLO II, drasi and UCESB.
Betreff: Re: [subexp-daq] NURDLIB - Problem in parser of caen_v1n90

Dear Günter,

if you are able to push to the master branch, we actually have a
configuration problem.  But also we do not push to the (remote) master
branch of each other's projects.

But in any case, please do not.

It is easy to push to a branch with another name:

git push <remote> <local-branch>:<remote-branch>

e.g.

git push origin master:fixes-of-something

...

Or you can just creat a new local branch name first

git branch <new-name>
git checkout <new-name>

and the do a

git push origin <new-name>

Cheers,
Håkan

On Tue, 16 Apr 2024, Weber, Guenter Dr. wrote:

>
> Dear friends,
>
>
> we have (most probably fixed) the issue by modifying the parser a bit. See
> attachment.
>
>
> Unfortunately, before doing the changes, I did not open a new branch. Am I
> allowed to commit our changes to the master branch? Or do  you want to
> implement the new parser (if you think it is fine this way)?
>
>
>
>
> Best greetings
>
> Günter
>
> ____________________________________________________________________________
> Von: Weber, Guenter Dr.
> Gesendet: Dienstag, 16. April 2024 07:11:32
> An: Discuss use of Nurdlib, TRLO II, drasi and UCESB.
> Betreff: NURDLIB - Problem in parser of caen_v1n90
>
> Dear friends,
>
>
> yesterday I managed to get the DAQ starting (using the updated software and
> howto instructions). However, the readout of the TDC module V1190A failed:
>
>
> 2024-04-15 14:29:36.979260 i  RIO4L-2/MAIN    crate_init(POLARIMETER) }
> +0200 CEST :f_user.c:1257:
> 2024-04-15 14:29:36.979280 E  RIO4L-2/MAIN    had readout error, ret=0x2,
> trigger=1, prev=1
> +0200 CEST :module/caen_v1n90/caen_v1n90.c:651:
> 2024-04-15 14:29:36.979684 E  RIO4L-2/MAIN    Trailer corrupt
> (ofs=0x00000010,u8[4]=0x0900032f).
> +0200 CEST :crate/crate.c:2074:
> 2024-04-15 14:29:36.979712 E  RIO4L-2/MAIN    POLARIMETER[3]=CAEN_V1190
> parse error=0x00000002, dumping data:
> +0200 CEST :crate/crate.c:2083:
> 2024-04-15 14:29:36.979724 i  RIO4L-2/MAIN    ---[ Dump begin ]---
> +0200 CEST :crate/crate.c:2083:
> 2024-04-15 14:29:36.979734 i  RIO4L-2/MAIN    Start=0x3005ef08
> Bytes=44=0x2c
> +0200 CEST :crate/crate.c:2083:
> 2024-04-15 14:29:36.979755 i  RIO4L-2/MAIN        0: 40000003 0800032f
> 00702106 18000003 0900032f 19000002 0a00032f 1a000002
> +0200 CEST :crate/crate.c:2083:
> 2024-04-15 14:29:36.979770 i  RIO4L-2/MAIN       20: 0b00032f 1b000002
> 80000163
> +0200 CEST :crate/crate.c:2083:
> 2024-04-15 14:29:36.979780 i  RIO4L-2/MAIN    ---[  Dump end  ]---
> +0200 CEST :crate/crate.c:1554:
> 2024-04-15 14:29:36.979810 E  RIO4L-2/MAIN    POLARIMETER: readout failed!
> +0200 CEST :crate/crate.c:1598:
> 2024-04-15 14:29:36.979823 E  RIO4L-2/MAIN    POLARIMETER: had problems,
> re-initializing.
>
>
> To us it looks like the parser does not account for the fact that the module
> contains several individual TDC units which each will produce a TDC header
> plus payload. And only after all TDC units were readout, finally the trailer
> will appear.
>
>
> (As I can see, the 1n90 series ranges from 16 channels to 128 channels with
> the high channel number modules having several individual TDC units. Maybe,
> this whole issue was overlooked when writing the parser code?)
>
>
> In the attachment, I send a modified version of the parser where for testing
> purposes it is assumed that the module has four TDC units (as should be the
> case for our module). Compilation of this code works, but it fails in the
> unit test with the following errors:
>
>
> make: Warning: File
> `build_cc_ppc-linux_4.2.2_debug/module/caen_v1n90/caen_v1n90.d' has
> modification time 45 s in the future
> CC    build_cc_ppc-linux_4.2.2_debug/module/caen_v1n90/caen_v1n90.o
> LD    build_cc_ppc-linux_4.2.2_debug/test
> TEST  build_cc_ppc-linux_4.2.2_debug/test_ok
> [tests/argmatch.c:127: Shorts]
> [tests/argmatch.c:128: Longs]
> [tests/argmatch.c:129: Combos]
> [tests/argmatch.c:130: ShortsWithValues]
> [tests/argmatch.c:131: LongsWithValues]
> [tests/argmatch.c:132: MissingValue]
> [tests/base.c:110: MemoryCheck]
> [tests/base.c:111: EventBufferAdvance]
> 2024-04-15,20:11:37:ERRR: Invalid pointer to advance event buffer.
> [tests/base.c:47]
> 2024-04-15,20:11:37:ERRR: Calling abort()... [tests/base.c:47]
> 2024-04-15,20:11:37:ERRR: Invalid pointer to advance event buffer.
> [tests/base.c:56]
> 2024-04-15,20:11:37:ERRR: Calling abort()... [tests/base.c:56]
> 2024-04-15,20:11:37:ERRR: Tried to advance outside event buffer.
> [tests/base.c:72]
> 2024-04-15,20:11:37:ERRR: Calling abort()... [tests/base.c:72]
> [tests/base.c:112: EventBufferInvariant]
> 2024-04-15,20:11:37:ERRR: Event-buffer inconsistent (0x103ae008:11 !=
> 0x103ae008:10). [tests/base.c:87]
> 2024-04-15,20:11:37:ERRR: Calling abort()... [tests/base.c:87]
> 2024-04-15,20:11:37:ERRR: Event-buffer inconsistent (0x103ae008:9 !=
> 0x103ae008:10). [tests/base.c:91]
> 2024-04-15,20:11:37:ERRR: Calling abort()... [tests/base.c:91]
> 2024-04-15,20:11:37:ERRR: Event-buffer inconsistent (0x103ae009:10 !=
> 0x103ae008:10). [tests/base.c:95]
> 2024-04-15,20:11:37:ERRR: Calling abort()... [tests/base.c:95]
> 2024-04-15,20:11:37:ERRR: Event-buffer inconsistent (0x103ae007:10 !=
> 0x103ae008:10). [tests/base.c:99]
> 2024-04-15,20:11:37:ERRR: Calling abort()... [tests/base.c:99]
>
> For comparison, I also send the parser from the NURDLIB version that Bastian
> had set up for us.
>
>
>
> It would be really great if you could have a look into this. Most probably
> this is the last issue that we are facing, before the DAQ is fine again.
>
>
>
>
> Thank you very much!
>
>
>
> Best greetings
>
> Günter
>
>
>
>
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.chalmers.se/pipermail/subexp-daq/attachments/20240417/ca76f877/attachment.html>