[subexp-daq] How to start a DAQ system after NURDLIB, TRLOII, DRASI, etc. were updated

Mon Jan 22 15:29:41 CET 2024

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.chalmers.se/pipermail/subexp-daq/attachments/20240122/6272de81/attachment-0001.html>