[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 11:25:45 CET 2024
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>>
>> >
>>
>>
>
More information about the subexp-daq
mailing list