[subexp-daq] How to start a DAQ system after NURDLIB, TRLOII, DRASI, etc. were updated
Hans Toshihide Törnqvist
hans.tornqvist at chalmers.se
Tue Jan 23 12:17:18 CET 2024
Dear Günter,
On 2024-01-23 11:53, Weber, Guenter Dr. wrote:
> Dear Hans,
>
> I do not know how to interpret "my-daq-node". But I found a similar
> command that Bastian once showed me. Is my-daq-note = localhost:8001?
Sorry I did not explain this part properly, but you found the correct value.
> mbsdaq at atpnbg011:~/mbsrun/rio4/2024_mcalstruck/ucesb/empty$ ./empty
> stream://localhost:8001 --print --data --max-events=10
> Event 23358 Type/Subtype 10 1 Size 140 Trigger 1
> SubEv ProcID 1 Type/Subtype 10 1 Size 24 Ctrl 9
> Subcrate 1
> 00000200 03e115f4 04e11396 05e12f3e 06e10001 f1a2000a
> SubEv ProcID 1 Type/Subtype 20 2 Size 84 Ctrl 9
> Subcrate 1
> 80000000 65d8a6db 00012f3e 139615f4 00000010 0032e025 00000000 00000000
> 00000000 00000000 00000000 00000000 00000000 00000001 00000001 00000001
> 00000001 00000001 00000001 00000001 00000001
>
> The last 16 entries of the LMD events are most probably the VULOM
> scalers, with the first channel incrementing by one for each trigger.
> Unclear to me is why the last 8 channels show a 1 instead of 0.
Do you know what is connected to the last 8 channels? What if you reset
the scalers before you start the DAQ, e.g.:
$VULOM4_CTRL --addr=... --mux-src-scalers=reset
> The 3rd and 4th entries belong to the 64-bit VULOM timestamp, probably.
Yes.
> Could you explain what the first two entries are? And the 5th?
Word 1: Readout status
The f-user builds this word based on the nurdlib readout result and the
r3bfuser config. Each bit has a special meaning which you can find in
ucesb/spec/land_std_vme.spec. Certain bits will expect certain data to
follow this first word, see next.
Word 2: Timestamp
Since the readout status has the most significant bit set (bit 31), the
next word is interpreted as a 32-bit timestamp. The r3bfuser puts its
computer time here.
Word 5: # of trloii scalers
The # of trloii scaler values that follow, 0x10 = 16.
Preferably the trloii readout should have provided a header with feature
bits to explain whether there are timestamps and scalers, but it is what
it is now...
There is also the issue of the Vetar not being read out. It would be
nice if the unpacker remained unchanged so you can read old and new
files with the same program.
If the Vetar is not needed since you read out the trloii timestamps, the
easiest fix for now would be to introduce two barrier words after the
Vulom. Nurdlib will not complain if there are too many, and Vetar
timestamps can take on any value so the barrier words should be accepted
by the unpacker.
I will try to go through the sis3316 merge soon.
Best regards,
Hans
> Many thanks and best greetings
>
> Günter
>
>
>
>
> ------------------------------------------------------------------------
> *Von:* subexp-daq <subexp-daq-bounces at lists.chalmers.se> im Auftrag von
> Hans Toshihide Törnqvist <hans.tornqvist at chalmers.se>
> *Gesendet:* Dienstag, 23. Januar 2024 11:25:45
> *An:* Discuss use of Nurdlib, TRLO II, drasi and UCESB.
> *Betreff:* Re: [subexp-daq] How to start a DAQ system after NURDLIB,
> TRLOII, DRASI, etc. were updated
> Dear Günter,
>
> I will have to look into the merge I did of the 'mcal_daq' and 'master'
> changes for the sis3316. It is a very complex module with by far the
> most complex code that I do not know very well, so it is very likely
> that I made a mistake.
>
> You should have a ucesb/ directory, and inside there is hopefully an
> already built binary ucesb/empty/empty. If not:
>
> cd ucesb
> make empty -j8
>
> You can then use it like this:
>
> cd ucesb/empty
> ./empty --stream=my-daq-node --print --data --max-events=10
>
> You can also save a raw data file:
>
> ./empty --stream=my-daq-node --output=my-test-file.lmd --max-events=10
>
> and look at that:
>
> ./empty my-test-file.lmd --print --data
>
> Best regards,
> Hans
>
> On 2024-01-23 11:05, Weber, Guenter Dr. wrote:
>> Dear Håkan,
>>
>>
>> as far as I know we never touched the SIS3316 firmware. But, as you know
>> by now, I know every little about the details of our DAQ, unfortunately.
>>
>>
>> Just for checking, I now removed the SIS3316 entries from main.cfg.
>> Thus, after also eliminating the VETAR, we just have the VULOM. And now
>> I don't get any errors:
>>
>>
>> 10: lwroc_hostname_util.c:108: Host 'lyserv' known as 192.168.1.1 (port:
>> 56583).
>> Thread has no error buffer yet...
>> CPUS: 1
>> delay: 1
>> 10: lwroc_hostname_util.c:108: Host 'lyserv' known as 192.168.1.1 (port:
>> 56583).
>> Thread has no error buffer yet...
>> HOST: RIO4-MCAL-1
>> Token: d6d68d7b (d6d68d7b:d6d68d7b) [/mbsusr/mbsdaq/.drasi_tokens/mcal]
>> 10: lwroc_hostname_util.c:457: Own address: 192.168.1.71/255.255.255.0
>> (eth1).
>> 10: lwroc_data_pipe.c:145: Data buffer READOUT_PIPE, size 419430400 =
>> 0x19000000, 1 consumers.
>> 10: lwroc_triva_readout.c:66: Silence TRIVA (HALT)
>> 10: lwroc_net_io.c:167: Started server on port 56583 (data port 39340).
>> client union size: 244 208 188 508 640 204 204 => 640
>> 10: lwroc_udp_awaken_hints.c:159: UDP awaken hints file:
>> /tmp/drasi.u1001/drasi.hints.u1001.RIO4-MCAL-1:56583
>> 10: lwroc_main.c:706: Log message rate limit not in effect.
>> 10: lwroc_readout.c:112: call readout_init...
>> 10: lwroc_thread_util.c:117: This is the triva control thread!
>> 10: lwroc_thread_util.c:117: This is the net io thread!
>> 10: lwroc_thread_util.c:117: This is the slow_async thread!
>> 10: lwroc_thread_util.c:117: This is the data server thread!
>> 10: lwroc_message_internal.c:472: Message client connected!
>> 10: lwroc_net_trans.c:1156: [drasi] Transport client connected (data)
>> [192.168.1.1].
>> 10: lwroc_triva_control.c:370: Setup TRIVA (DISBUS, HALT, MASTER, RESET)
>> 10: lwroc_triva_control.c:418: Minimum event time
>> ctime(5000)+1*rd(689)+3*wr(634)+fctime(1000)=8591 ns (116.401 kHz)
>> 10: lwroc_triva_state.c:1486: (Re)send ident messages...
>> 10: lwroc_triva_control.c:495: START TEST ACQ: HALT, CLEAR=RESET, MT=1
>> 9: lwroc_triva_control.c:507: TEST: GO
>> 10: lwroc_triva_control.c:725: RUN: RESET
>> 10: lwroc_triva_control.c:729: RUN: MT=14
>> 9: lwroc_triva_control.c:737: GO (1 good test triggers done) (max
>> 116.4 kHz)
>> 10: lwroc_triva_readout.c:376: Trigger 14 seen.
>> 10: config/config.c:181: Will try default cfg
>> path='/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default', can be set with NURDLIB_DEF_PATH.
>> 8: lwroc_triva_state.c:2399: Master: deadtime: 1. Status: 0x10
>> (IN_READOUT). EC: 1
>> 10: lwroc_triva_state.c:2428: [EB lyserv] EB: Status: 0x0.
>> 8: lwroc_triva_state.c:2488: Node(s) busy in readout, waiting...
>> 10: config/parser.c:287: Opened
>> '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/global.cfg' {
>> 10: config/parser.c:299: Closed
>> '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/global.cfg' }
>> 10: config/parser.c:287: Opened './main.cfg' {
>> 10: config/config.c:1299: .Global log level=verbose.
>> 10: config/parser.c:287: .Opened
>> '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/crate.cfg' {
>> 10: config/parser.c:299: .Closed
>> '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/crate.cfg' }
>> 10: config/parser.c:287: .Opened
>> '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/gsi_vulom.cfg' {
>> 10: config/parser.c:299: .Closed
>> '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/gsi_vulom.cfg' }
>> 10: config/parser.c:287: .Opened
>> '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/module_log_level.cfg' {
>> 10: config/parser.c:299: .Closed
>> '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/module_log_level.cfg' }
>> 10: config/parser.c:299: Closed './main.cfg' }
>> 10: crate/crate.c:347: crate_create {
>> 10: crate/crate.c:673: crate_create(MCAL) }
>> 10: crate/crate.c:899: crate_init(MCAL) {
>> 10: crate/crate.c:923: .Slow-init module[0]=GSI_VULOM.
>> LOG: TRLO: MD5SUM: 0x1409285e (CT: 63bb1d44 = 2023-01-08 19:45:08 UTC)
>> 10: crate/crate.c:976: .Fast-init module[0]=GSI_VULOM.
>> 10: crate/crate.c:1073: crate_init(MCAL) }
>> 10: ctrl/ctrl.c:788: Control server online.
>> Thread has no error buffer yet...
>> 10: f_user.c:559: WR ID=0x200.
>> 10: f_user.c:565: TS offset unset. Will not modify stamp.
>> 10: f_user.c:572: TPAT: No.
>> 10: f_user.c:573: Sync-check: No.
>> 10: f_user.c:575: Spill triggers: No.
>> 10: f_user.c:576: LMU: No.
>> 10: f_user.c:577: Timer latches: No.
>> 10: f_user.c:578: Spill shape: No.
>> 10: f_user.c:579: Micro-structure: No.
>> 10: f_user.c:581: Multi-event flag: No.
>> 10: f_user.c:586: UDP destination: None.
>>
>> The DAQ is running with 10 Hz, as expected. Is there an easy way to look
>> at the output of the DAQ? This should now contain only of the time stamp
>> and the 16 scaler channels from the VULOM. If we can verify that this
>> minimum example is now running as expected, we can go back to debugging
>> the SIS3316 part, ok?
>>
>>
>>
>>
>> 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:* Montag, 22. Januar 2024 23:01:43
>> *An:* Discuss use of Nurdlib, TRLO II, drasi and UCESB.
>> *Betreff:* Re: [subexp-daq] How to start a DAQ system after NURDLIB,
>> TRLOII, DRASI, etc. were updated
>>
>> Dear Günter,
>>
>> The error would be the line
>>
>>> 5: module/sis_3316/sis_3316.c:3096: [2]: timeout while polling for previous bank addr (bank 0 != 0) on ch 0
>>
>> (the printout from lwroc_triva_state.c is basically debug help, just
>> trying to help identifying which system is stuck, in case one has multiple
>> crates (not the case here).)
>>
>> Question: when the modules are re-inited (which always happens after
>> readout failure), it looks like the two SIS3316 modules have different
>> firmwares?
>>
>> Is that intentional?
>>
>> How do those values compare to the other DAQ system?
>>
>> Best regards,
>> Håkan
>>
>>
>>
>> On Mon, 22 Jan 2024, Weber, Guenter Dr. wrote:
>>
>>>
>>> Dear Hans,
>>>
>>>
>>> thank you for the explanations for r3bfuser.cfg. In the end only a single cryptic line remains in this file, right?
>>>
>>>
>>> With the new R3B config and modified VULOM entry in main.cfg I get the following result:
>>>
>>>
>>> ... everything looks nice and the SIS3316 threshold are set ...
>>>
>>> 10: crate/crate.c:1008: .Post-init module[1]=SIS_3316.
>>> 10: crate/crate.c:1008: .Post-init module[2]=SIS_3316.
>>> 10: crate/crate.c:1073: crate_init(MCAL) }
>>> 5: f_user.c:1257: had readout error, ret=0x4, trigger=1, prev=1
>>> 8: lwroc_triva_state.c:2028: Master TRIVA/MI no progress last second, and in deadtime.
>>> 8: lwroc_triva_state.c:2399: Master: deadtime: 1. Status: 0x10 (IN_READOUT). EC: 5
>>> 10: lwroc_triva_state.c:2428: [EB lyserv] EB: Status: 0x0.
>>> 8: lwroc_triva_state.c:2488: Node(s) busy in readout, waiting...
>>> 8: lwroc_triva_state.c:2028: Master TRIVA/MI no progress last second, and in deadtime.
>>> 8: lwroc_triva_state.c:2399: Master: deadtime: 1. Status: 0x10 (IN_READOUT). EC: 5
>>> 10: lwroc_triva_state.c:2428: [EB lyserv] EB: Status: 0x0.
>>> 8: lwroc_triva_state.c:2488: Node(s) busy in readout, waiting...
>>> 8: lwroc_triva_state.c:2028: Master TRIVA/MI no progress last second, and in deadtime.
>>> 8: lwroc_triva_state.c:2399: Master: deadtime: 1. Status: 0x10 (IN_READOUT). EC: 5
>>> 10: lwroc_triva_state.c:2428: [EB lyserv] EB: Status: 0x0.
>>> 8: lwroc_triva_state.c:2488: Node(s) busy in readout, waiting...
>>> 8: lwroc_triva_state.c:2028: Master TRIVA/MI no progress last second, and in deadtime.
>>> 8: lwroc_triva_state.c:2399: Master: deadtime: 1. Status: 0x10 (IN_READOUT). EC: 5
>>> 10: lwroc_triva_state.c:2428: [EB lyserv] EB: Status: 0x0.
>>> 8: lwroc_triva_state.c:2488: Node(s) busy in readout, waiting...
>>> 8: lwroc_triva_state.c:2028: Master TRIVA/MI no progress last second, and in deadtime.
>>> 8: lwroc_triva_state.c:2399: Master: deadtime: 1. Status: 0x10 (IN_READOUT). EC: 5
>>> 10: lwroc_triva_state.c:2428: [EB lyserv] EB: Status: 0x0.
>>> 8: lwroc_triva_state.c:2488: Node(s) busy in readout, waiting...
>>> 5: module/sis_3316/sis_3316.c:3096: [2]: timeout while polling for previous bank addr (bank 0 != 0) on ch 0
>>> 5: module/sis_3316/sis_3316.c:2512: sis3316 bank of channel not ready for readout.
>>> 5: module/sis_3316/sis_3316.c:2329: sis3316 ch[0] test_channel failed
>>> 5: crate/crate.c:1954: MCAL[2]=SIS_3316 readout error=0x00000004, dumping data:
>>> 10: crate/crate.c:1970: ---[ Dump begin ]---
>>> 10: crate/crate.c:1970: Start=0x3005e230 Bytes=0=0x0
>>> 10: crate/crate.c:1970: ---[ Dump end ]---
>>> 5: crate/crate.c:1449: MCAL: readout failed!
>>> 5: crate/crate.c:1493: MCAL: had problems, re-initializing.
>>> 10: crate/crate.c:683: crate_deinit(MCAL) {
>>> 10: crate/crate.c:707: crate_deinit(MCAL) }
>>> 8: lwroc_triva_state.c:2028: Master TRIVA/MI no progress last second, and in deadtime.
>>> 8: lwroc_triva_state.c:2399: Master: deadtime: 1. Status: 0x10 (IN_READOUT). EC: 5
>>> 10: lwroc_triva_state.c:2428: [EB lyserv] EB: Status: 0x0.
>>> 8: lwroc_triva_state.c:2488: Node(s) busy in readout, waiting...
>>> 10: crate/crate.c:899: crate_init(MCAL) {
>>> 10: crate/crate.c:923: .Slow-init module[0]=GSI_VULOM.
>>> LOG: TRLO: MD5SUM: 0x1409285e (CT: 63bb1d44 = 2023-01-08 19:45:08 UTC)
>>> 10: crate/crate.c:923: .Slow-init module[1]=SIS_3316.
>>> 10: module/map/map.c:224: ...rd(0x30000000+0x64/32)=535ns wr(0x30000000+0x64/32)=356ns.
>>> 10: module/sis_3316/sis_3316.c:1355: ..Serial number=0x00800178.
>>> 10: module/sis_3316/sis_3316.c:1362: ..id/firmware=0x3316200e.
>>> 10: module/sis_3316/sis_3316.c:1365: ..adc[0] firmware=0x0125000c.
>>> 10: module/sis_3316/sis_3316.c:1365: ..adc[1] firmware=0x0125000c.
>>> 10: module/sis_3316/sis_3316.c:1365: ..adc[2] firmware=0x0125000c.
>>> 10: module/sis_3316/sis_3316.c:1365: ..adc[3] firmware=0x0125000c.
>>> 8: lwroc_triva_state.c:2028: Master TRIVA/MI no progress last second, and in deadtime.
>>> 8: lwroc_triva_state.c:2399: Master: deadtime: 1. Status: 0x10 (IN_READOUT). EC: 5
>>> 10: lwroc_triva_state.c:2428: [EB lyserv] EB: Status: 0x0.
>>> 8: lwroc_triva_state.c:2488: Node(s) busy in readout, waiting...
>>> 8: lwroc_triva_state.c:2028: Master TRIVA/MI no progress last second, and in deadtime.
>>> 8: lwroc_triva_state.c:2399: Master: deadtime: 1. Status: 0x10 (IN_READOUT). EC: 5
>>> 10: lwroc_triva_state.c:2428: [EB lyserv] EB: Status: 0x0.
>>> 8: lwroc_triva_state.c:2488: Node(s) busy in readout, waiting...
>>> 8: lwroc_triva_state.c:2028: Master TRIVA/MI no progress last second, and in deadtime.
>>> 8: lwroc_triva_state.c:2399: Master: deadtime: 1. Status: 0x10 (IN_READOUT). EC: 5
>>> 10: lwroc_triva_state.c:2428: [EB lyserv] EB: Status: 0x0.
>>> 8: lwroc_triva_state.c:2488: Node(s) busy in readout, waiting...
>>> 10: crate/crate.c:923: .Slow-init module[2]=SIS_3316.
>>> 10: module/map/map.c:224: ...rd(0x31000000+0x64/32)=540ns wr(0x31000000+0x64/32)=360ns.
>>> 10: module/sis_3316/sis_3316.c:1355: ..Serial number=0x008001a7.
>>> 10: module/sis_3316/sis_3316.c:1362: ..id/firmware=0x33162010.
>>> 10: module/sis_3316/sis_3316.c:1365: ..adc[0] firmware=0x01250011.
>>> 10: module/sis_3316/sis_3316.c:1365: ..adc[1] firmware=0x01250011.
>>> 10: crate/crate.c:923: .Slow-init module[2]=SIS_3316.
>>> 10: module/map/map.c:224: ...rd(0x31000000+0x64/32)=540ns wr(0x31000000+0x64/32)=360ns.
>>> 10: module/sis_3316/sis_3316.c:1355: ..Serial number=0x008001a7.
>>> 10: module/sis_3316/sis_3316.c:1362: ..id/firmware=0x33162010.
>>> 10: module/sis_3316/sis_3316.c:1365: ..adc[0] firmware=0x01250011.
>>> 10: module/sis_3316/sis_3316.c:1365: ..adc[1] firmware=0x01250011.
>>> 10: module/sis_3316/sis_3316.c:1365: ..adc[2] firmware=0x01250011.
>>> 10: module/sis_3316/sis_3316.c:1365: ..adc[3] firmware=0x01250011.
>>> ^C8: lwroc_main.c:106: SIGINT received.
>>>
>>> I stopped the DAQ software manually. To me it looked like, the software tried every 10 seconds to restart the DAQ.
>>>
>>>
>>> The DAQ setup consists of 1 RIO, 1 TRIVA, 1 VULOM B, 2 SIS3316, 1 VETAR2.
>>>
>>> The VULOM provides two output signals. A fast one to synchronize the SIS3316 modules and a slow one (10 Hz) that is used for triggering the DAQ. In this test setup no external signals are fed to the digitizers.
>>>
>>>
>>>
>>>
>>>
>>> Best greetings
>>>
>>> Günter
>>>
>>>
>>>
>>> _______________________________________________________________________________________________________________________________________________________________________________________________________________________________
>>> Von: subexp-daq <subexp-daq-bounces at lists.chalmers.se> im Auftrag von Hans Toshihide Törnqvist <hans.tornqvist at chalmers.se>
>>> Gesendet: Montag, 22. Januar 2024 15:57:24
>>> An: Discuss use of Nurdlib, TRLO II, drasi and UCESB.
>>> Betreff: Re: [subexp-daq] How to start a DAQ system after NURDLIB, TRLOII, DRASI, etc. were updated
>>> Dear Günter,
>>>
>>> It seems also the r3bfuser configuration parser was updated. I took the
>>> file you sent us on the 18th and updated it, with some explanations to
>>> the changes.
>>>
>>> The SIS3316 modules do not need the barrier between. Note that with the
>>> changed main.cfg, the data will be different and the unpacker may have
>>> some problems, but let's get the DAQ running first :)
>>>
>>> Best regards,
>>> Hans
>>>
>>> On 2024-01-22 15:29, Weber, Guenter Dr. wrote:
>>> > Dear Hans,
>>> >
>>> >
>>> > yes, the VETAR does not have an upstream connection. My impression was
>>> > that in this case, the internal clock simply starts incrementing more or
>>> > less in the same way the VULOM does. I have now commented out the VETAR.
>>> > This is the result:
>>> >
>>> >
>>> > 10: lwroc_hostname_util.c:108: Host 'lyserv' known as 192.168.1.1 (port:
>>> > 56583).
>>> > Thread has no error buffer yet...
>>> > CPUS: 1
>>> > delay: 1
>>> > 10: lwroc_hostname_util.c:108: Host 'lyserv' known as 192.168.1.1 (port:
>>> > 56583).
>>> > Thread has no error buffer yet...
>>> > HOST: RIO4-MCAL-1
>>> > Token: d6d68d7b (d6d68d7b:d6d68d7b) [/mbsusr/mbsdaq/.drasi_tokens/mcal]
>>> > 10: lwroc_hostname_util.c:457: Own address: 192.168.1.71/255.255.255.0
>>> > (eth1).
>>> > 10: lwroc_data_pipe.c:145: Data buffer READOUT_PIPE, size 419430400 =
>>> > 0x19000000, 1 consumers.
>>> > 10: lwroc_triva_readout.c:66: Silence TRIVA (HALT)
>>> > 10: lwroc_net_io.c:167: Started server on port 56583 (data port 51756).
>>> > client union size: 244 208 188 508 640 204 204 => 640
>>> > 10: lwroc_udp_awaken_hints.c:159: UDP awaken hints file:
>>> > /tmp/drasi.u1001/drasi.hints.u1001.RIO4-MCAL-1:56583
>>> > 10: lwroc_main.c:706: Log message rate limit not in effect.
>>> > 10: lwroc_readout.c:112: call readout_init...
>>> > 10: lwroc_thread_util.c:117: This is the triva control thread!
>>> > 10: lwroc_thread_util.c:117: This is the net io thread!
>>> > 10: lwroc_thread_util.c:117: This is the slow_async thread!
>>> > 10: lwroc_thread_util.c:117: This is the data server thread!
>>> > 10: lwroc_message_internal.c:472: Message client connected!
>>> > 10: lwroc_net_trans.c:1156: [drasi] Transport client connected (data)
>>> > [192.168.1.1].
>>> > 10: lwroc_triva_control.c:370: Setup TRIVA (DISBUS, HALT, MASTER, RESET)
>>> > 10: lwroc_triva_control.c:418: Minimum event time
>>> > ctime(5000)+1*rd(691)+3*wr(633)+fctime(1000)=8590 ns (116.414 kHz)
>>> > 10: lwroc_triva_state.c:1486: (Re)send ident messages...
>>> > 10: lwroc_triva_control.c:495: START TEST ACQ: HALT, CLEAR=RESET, MT=1
>>> > 9: lwroc_triva_control.c:507: TEST: GO
>>> > 10: lwroc_triva_control.c:725: RUN: RESET
>>> > 10: lwroc_triva_control.c:729: RUN: MT=14
>>> > 9: lwroc_triva_control.c:737: GO (1 good test triggers done) (max
>>> > 116.4 kHz)
>>> > 10: lwroc_triva_readout.c:376: Trigger 14 seen.
>>> > 10: config/config.c:181: Will try default cfg
>>> > path='/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default', can be set with NURDLIB_DEF_PATH.
>>> > 10: config/parser.c:287: Opened
>>> > '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/global.cfg' {
>>> > 10: config/parser.c:299: Closed
>>> > '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/global.cfg' }
>>> > 8: lwroc_triva_state.c:2399: Master: deadtime: 1. Status: 0x10
>>> > (IN_READOUT). EC: 1
>>> > 10: lwroc_triva_state.c:2428: [EB lyserv] EB: Status: 0x0.
>>> > 8: lwroc_triva_state.c:2488: Node(s) busy in readout, waiting...
>>> > 10: config/parser.c:287: Opened './main.cfg' {
>>> > 10: config/config.c:1299: .Global log level=verbose.
>>> > 10: config/parser.c:287: .Opened
>>> > '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/crate.cfg' {
>>> > 10: config/parser.c:299: .Closed
>>> > '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/crate.cfg' }
>>> > 10: config/parser.c:287: .Opened
>>> > '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/gsi_vulom.cfg' {
>>> > 10: config/parser.c:299: .Closed
>>> > '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/gsi_vulom.cfg' }
>>> > 10: config/parser.c:287: .Opened
>>> > '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/module_log_level.cfg' {
>>> > 10: config/parser.c:299: .Closed
>>> > '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/module_log_level.cfg' }
>>> > 10: config/parser.c:287: .Opened
>>> > '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/sis_3316.cfg' {
>>> > 10: config/parser.c:299: .Closed
>>> > '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/sis_3316.cfg' }
>>> > 10: config/parser.c:287: .Opened
>>> > '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/module_log_level.cfg' {
>>> > 10: config/parser.c:299: .Closed
>>> > '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/module_log_level.cfg' }
>>> > 10: config/parser.c:287: .Opened
>>> > '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/sis_3316.cfg' {
>>> > 10: config/parser.c:299: .Closed
>>> > '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/sis_3316.cfg' }
>>> > 10: config/parser.c:287: .Opened
>>> > '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/module_log_level.cfg' {
>>> > 10: config/parser.c:299: .Closed
>>> > '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/module_log_level.cfg' }
>>> > 10: config/parser.c:299: Closed './main.cfg' }
>>> > 10: crate/crate.c:347: crate_create {
>>> > 10: crate/crate.c:673: crate_create(MCAL) }
>>> > 10: crate/crate.c:899: crate_init(MCAL) {
>>> > 10: crate/crate.c:923: .Slow-init module[0]=GSI_VULOM.
>>> > LOG: TRLO: MD5SUM: 0x1409285e (CT: 63bb1d44 = 2023-01-08 19:45:08 UTC)
>>> > 10: crate/crate.c:923: .Slow-init module[1]=SIS_3316.
>>> > 10: module/map/map.c:224: ...rd(0x30000000+0x64/32)=535ns
>>> > wr(0x30000000+0x64/32)=356ns.
>>> > 10: module/sis_3316/sis_3316.c:1355: ..Serial number=0x00800178.
>>> > 10: module/sis_3316/sis_3316.c:1362: ..id/firmware=0x3316200e.
>>> > 10: module/sis_3316/sis_3316.c:1365: ..adc[0] firmware=0x0125000c.
>>> > 10: module/sis_3316/sis_3316.c:1365: ..adc[1] firmware=0x0125000c.
>>> > 10: module/sis_3316/sis_3316.c:1365: ..adc[2] firmware=0x0125000c.
>>> > 10: module/sis_3316/sis_3316.c:1365: ..adc[3] firmware=0x0125000c.
>>> > 8: lwroc_triva_state.c:2028: Master TRIVA/MI no progress last second,
>>> > and in deadtime.
>>> > 8: lwroc_triva_state.c:2399: Master: deadtime: 1. Status: 0x10
>>> > (IN_READOUT). EC: 1
>>> > 10: lwroc_triva_state.c:2428: [EB lyserv] EB: Status: 0x0.
>>> > 8: lwroc_triva_state.c:2488: Node(s) busy in readout, waiting...
>>> > 8: lwroc_triva_state.c:2028: Master TRIVA/MI no progress last second,
>>> > and in deadtime.
>>> > 8: lwroc_triva_state.c:2399: Master: deadtime: 1. Status: 0x10
>>> > (IN_READOUT). EC: 1
>>> > 10: lwroc_triva_state.c:2428: [EB lyserv] EB: Status: 0x0.
>>> > 8: lwroc_triva_state.c:2488: Node(s) busy in readout, waiting...
>>> > 10: crate/crate.c:923: .Slow-init module[2]=SIS_3316.
>>> > 10: module/map/map.c:224: ...rd(0x31000000+0x64/32)=540ns
>>> > wr(0x31000000+0x64/32)=360ns.
>>> > 10: module/sis_3316/sis_3316.c:1355: ..Serial number=0x008001a7.
>>> > 10: module/sis_3316/sis_3316.c:1362: ..id/firmware=0x33162010.
>>> > 10: module/sis_3316/sis_3316.c:1365: ..adc[0] firmware=0x01250011.
>>> > 10: module/sis_3316/sis_3316.c:1365: ..adc[1] firmware=0x01250011.
>>> > 10: module/sis_3316/sis_3316.c:1365: ..adc[2] firmware=0x01250011.
>>> > 10: module/sis_3316/sis_3316.c:1365: ..adc[3] firmware=0x01250011.
>>> > 8: lwroc_triva_state.c:2028: Master TRIVA/MI no progress last second,
>>> > and in deadtime.
>>> > 8: lwroc_triva_state.c:2399: Master: deadtime: 1. Status: 0x10
>>> > (IN_READOUT). EC: 1
>>> > 10: lwroc_triva_state.c:2428: [EB lyserv] EB: Status: 0x0.
>>> > 8: lwroc_triva_state.c:2488: Node(s) busy in readout, waiting...
>>> > 10: crate/crate.c:976: .Fast-init module[0]=GSI_VULOM.
>>> > 10: crate/crate.c:976: .Fast-init module[1]=SIS_3316.
>>> > 10: module/sis_3316/sis_3316.c:4177: ...threshold[0] = 8 mV -> 0x0800010a
>>> > 10: module/sis_3316/sis_3316.c:4177: ...threshold[1] = 8 mV -> 0x0800010a
>>> > 10: module/sis_3316/sis_3316.c:4177: ...threshold[2] = 8 mV -> 0x0800010a
>>> > 10: module/sis_3316/sis_3316.c:4177: ...threshold[3] = 15 mV -> 0x080001f3
>>> > 10: module/sis_3316/sis_3316.c:4177: ...threshold[4] = 8 mV -> 0x0800010a
>>> > 10: module/sis_3316/sis_3316.c:4177: ...threshold[5] = 8 mV -> 0x0800010a
>>> > 10: module/sis_3316/sis_3316.c:4177: ...threshold[6] = 10 mV -> 0x0800014c
>>> > 10: module/sis_3316/sis_3316.c:4177: ...threshold[7] = 8 mV -> 0x0800010a
>>> > 10: module/sis_3316/sis_3316.c:4177: ...threshold[8] = 8 mV -> 0x0800010a
>>> > 10: module/sis_3316/sis_3316.c:4177: ...threshold[9] = 8 mV -> 0x0800010a
>>> > 10: module/sis_3316/sis_3316.c:4177: ...threshold[10] = 13 mV -> 0x080001b0
>>> > 10: module/sis_3316/sis_3316.c:4177: ...threshold[11] = 8 mV -> 0x0800010a
>>> > 10: module/sis_3316/sis_3316.c:4177: ...threshold[12] = 8 mV -> 0x0800010a
>>> > 10: module/sis_3316/sis_3316.c:4177: ...threshold[13] = 8 mV -> 0x0800010a
>>> > 10: module/sis_3316/sis_3316.c:4177: ...threshold[14] = 8 mV -> 0x0800010a
>>> > 10: module/sis_3316/sis_3316.c:4177: ...threshold[15] = 15 mV -> 0x080001f3
>>> > 10: crate/crate.c:976: .Fast-init module[2]=SIS_3316.
>>> > 10: module/sis_3316/sis_3316.c:4177: ...threshold[0] = 10 mV -> 0x0800014c
>>> > 10: module/sis_3316/sis_3316.c:4177: ...threshold[1] = 8 mV -> 0x0800010a
>>> > 10: module/sis_3316/sis_3316.c:4177: ...threshold[2] = 8 mV -> 0x0800010a
>>> > 10: module/sis_3316/sis_3316.c:4177: ...threshold[3] = 8 mV -> 0x0800010a
>>> > 10: module/sis_3316/sis_3316.c:4177: ...threshold[4] = 8 mV -> 0x0800010a
>>> > 10: module/sis_3316/sis_3316.c:4177: ...threshold[5] = 10 mV -> 0x0800014c
>>> > 10: module/sis_3316/sis_3316.c:4177: ...threshold[6] = 13 mV -> 0x080001b0
>>> > 10: module/sis_3316/sis_3316.c:4177: ...threshold[7] = 8 mV -> 0x0800010a
>>> > 10: module/sis_3316/sis_3316.c:4177: ...threshold[8] = 8 mV -> 0x0800010a
>>> > 10: module/sis_3316/sis_3316.c:4177: ...threshold[9] = 8 mV -> 0x0800010a
>>> > 10: module/sis_3316/sis_3316.c:4177: ...threshold[10] = 8 mV -> 0x0800010a
>>> > 10: module/sis_3316/sis_3316.c:4177: ...threshold[11] = 8 mV -> 0x0800010a
>>> > 10: module/sis_3316/sis_3316.c:4177: ...threshold[12] = 8 mV -> 0x0800010a
>>> > 10: module/sis_3316/sis_3316.c:4177: ...threshold[13] = 8 mV -> 0x0800010a
>>> > 10: module/sis_3316/sis_3316.c:4177: ...threshold[14] = 8 mV -> 0x0800010a
>>> > 10: module/sis_3316/sis_3316.c:4177: ...threshold[15] = 8 mV -> 0x0800010a
>>> > 10: crate/crate.c:1008: .Post-init module[1]=SIS_3316.
>>> > 10: crate/crate.c:1008: .Post-init module[2]=SIS_3316.
>>> > 10: crate/crate.c:1073: crate_init(MCAL) }
>>> > 10: ctrl/ctrl.c:788: Control server online.
>>> > Thread has no error buffer yet...
>>> > 5: f_user.c:484: r3bfuser.cfg:1: Weird config!
>>> > 5: f_user.c:484: Calling abort()...
>>> >
>>> >
>>> > Looks like the DAQ is able to set the thresholds for the first two
>>> > SIS3316 modules. And then crashes. But there are only these two modules,
>>> > so the main.cfg is done. I just noticed that I did not put a BARRIER
>>> > between the initialization of the two SIS3316 modules. Is this relevant?
>>> > But if it was, the problem would probably occur after the first module
>>> > and not when the main.cfg was completely processed.
>>> >
>>> >
>>> >
>>> >
>>> >
>>> > Best greetings
>>> >
>>> > Günter
>>> >
>>> >
>>> >
>>> > ------------------------------------------------------------------------
>>> > *Von:* subexp-daq <subexp-daq-bounces at lists.chalmers.se> im Auftrag von
>>> > Hans Toshihide Törnqvist <hans.tornqvist at chalmers.se>
>>> > *Gesendet:* Montag, 22. Januar 2024 15:18:20
>>> > *An:* Discuss use of Nurdlib, TRLO II, drasi and UCESB.
>>> > *Betreff:* Re: [subexp-daq] How to start a DAQ system after NURDLIB,
>>> > TRLOII, DRASI, etc. were updated
>>> > Dear Günter,
>>> >
>>> > Do you have a schematic of the setup? I.e. what modules have what
>>> > connections, in the crate and to detectors.
>>> >
>>> > Some photos would also be nice.
>>> >
>>> > This would help our understanding of the setup.
>>> >
>>> > Best regards,
>>> > Hans & Håkan
>>> > --
>>> > subexp-daq mailing list
>>> > subexp-daq at lists.chalmers.se
>>> > https://lists.chalmers.se/mailman/listinfo/subexp-daq
> <https://lists.chalmers.se/mailman/listinfo/subexp-daq>
>> <https://lists.chalmers.se/mailman/listinfo/subexp-daq
> <https://lists.chalmers.se/mailman/listinfo/subexp-daq>>
>>> > <https://lists.chalmers.se/mailman/listinfo/subexp-daq
>> <https://lists.chalmers.se/mailman/listinfo/subexp-daq
> <https://lists.chalmers.se/mailman/listinfo/subexp-daq>>>
>>> >
>>>
>>>
>>
> --
> subexp-daq mailing list
> subexp-daq at lists.chalmers.se
> https://lists.chalmers.se/mailman/listinfo/subexp-daq
> <https://lists.chalmers.se/mailman/listinfo/subexp-daq>
>
More information about the subexp-daq
mailing list