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

[Håkan T Johansson]

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
> 
> 
> 
> 
> 
> 
> 
>