[subexp-daq] How to start a DAQ system after NURDLIB, TRLOII, DRASI, etc. were updated
Hans Toshihide Törnqvist
hans.tornqvist at chalmers.se
Wed Jan 24 12:37:25 CET 2024
Dear Günter,
This is puzzling... To explain:
If r3bfuser.cfg has wr_id set, the init phase will query nurdlib for
modules that can deliver timestamps. This error message will show up if
no timestamping module was found and the process will abort.
Init must finish before the readout loop can start.
So, if wr_id is set and both vulom and vetar are commented, the DAQ
should abort. Should not matter how the sis3316 is configured.
If you let any of vulom or vetar uncommented, init will query first the
vetar and then the vulom. This happens in r3bfuser.c starting on line 722.
I would suggest that you either comment out wr_id in r3bfuser.cfg, or
you put back the vulom in main.cfg. Since the vetar has other problems
let's ignore it for now.
Best regards,
Hans
On 2024-01-24 11:48, Weber, Guenter Dr. wrote:
> Small update:
>
>
> If no channel of the SIS3316 module is not read out, then the DAQ is
> running smoothly. As soon as I want to read out one channel, the error
> message is triggered.
>
>
>
>
> Best greetings
>
> Günter
>
>
> ------------------------------------------------------------------------
> *Von:* subexp-daq <subexp-daq-bounces at lists.chalmers.se> im Auftrag von
> Weber, Guenter Dr. <g.weber at hi-jena.gsi.de>
> *Gesendet:* Mittwoch, 24. Januar 2024 11:23:19
> *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 friends,
>
>
> I now wanted to turn thing around and only have a single SIS3316 module
> in the DAQ. So I commented out the VULOM in main.cfg. However, now the
> r3bfuser.cfg needs to change, I guess.
>
>
> 5: f_user.c:745: User set WR ID=0x200, but no WR-capable module
> configured for nurdlib!
>
>
> What would be the correct R3B setting now with just a SIS3316 module in
> main.cfg? Or is the way to go, not to comment out the complete VULOM
> entry but just the timestamp and ecl options, i. e. having only
>
>
> GSI_VETAR(0x50000000) {
> # dactl = false
> # direct = false
> }
>
>
> ?
>
>
>
>
> 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:* Mittwoch, 24. Januar 2024 06:42: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,
>
> before you do a lot of module surgery:
>
> given that the merge of the changes you had in nurdlib in the 'old' but
> working daq into current nurdlib was a veritable monster, we have figured
> that those need to be more carefully considered, piece-by-piece. With
> some luck, some inadvertent mistake in the merge operation is perhaps
> found.
>
> This might take a few days...
>
> If that does not work, one can dump the full register set in the modules
> in both the 'old' and 'new' daqs after setup and compare those, which
> would then hopefully hint at what is not the same.
>
> But the code inspection is a safer long-term approach, so we prefer to do
> that first.
>
> Best regards,
> Håkan
>
>
>
> On Tue, 23 Jan 2024, Hans Toshihide Törnqvist wrote:
>
>> Dear Günter,
>>
>> Are you using different main.cfg files for the new and old DAQ?
>>
>> Could you add "log_level = verbose" or "log_level = debug" in the new
>> main.cfg if it's not there? That should print a lot more information.
>>
>> Note that all that text ends up in the log, have a look at it so it does
>> not explode in size, especially if you set " = debug"!
>>
>> Please try to recreate the crate setup with the same firmware versions
>> and addresses etc like before, that will reduce the number of free
>> variables in the testing.
>>
>> Best regards,
>> Hans
>>
>>
>> On 2024-01-23 16:12, Weber, Guenter Dr. wrote:
>>> Dear Håkan,
>>>
>>>
>>> the ADC firmware is printed right after the firmware of the VME module:
>>>
>>>
>>> 0: a:1: ..Serial number=0x00800172. (module/sis_3316/sis_3316.c:1305)
>>> 10: a:1: ..id/firmware=0x33162010. (module/sis_3316/sis_3316.c:1312)
>>> 10: a:1: ..adc[0] firmware=0x01250911. (module/sis_3316/sis_3316.c:1315)
>>> 11: a:1: ..adc[0] has 16 bits. (module/sis_3316/sis_3316.c:1322)
>>> 10: a:1: ..adc[1] firmware=0x01250911. (module/sis_3316/sis_3316.c:1315)
>>> 11: a:1: ..adc[1] has 16 bits. (module/sis_3316/sis_3316.c:1322)
>>> 10: a:1: ..adc[2] firmware=0x01250911. (module/sis_3316/sis_3316.c:1315)
>>> 11: a:1: ..adc[2] has 16 bits. (module/sis_3316/sis_3316.c:1322)
>>> 10: a:1: ..adc[3] firmware=0x01250911. (module/sis_3316/sis_3316.c:1315)
>>> 11: a:1: ..adc[3] has 16 bits. (module/sis_3316/sis_3316.c:1322)
>>>
>>>
>>> and
>>>
>>>
>>> 10: a:1: ..Serial number=0x00800170. (module/sis_3316/sis_3316.c:1305)
>>> 10: a:1: ..id/firmware=0x3316a012. (module/sis_3316/sis_3316.c:1312)
>>> 10: a:1: ..adc[0] firmware=0x0125a012. (module/sis_3316/sis_3316.c:1315)
>>> 11: a:1: ..adc[0] has 16 bits. (module/sis_3316/sis_3316.c:1322)
>>> 10: a:1: ..adc[1] firmware=0x0125a012. (module/sis_3316/sis_3316.c:1315)
>>> 11: a:1: ..adc[1] has 16 bits. (module/sis_3316/sis_3316.c:1322)
>>> 10: a:1: ..adc[2] firmware=0x0125a012. (module/sis_3316/sis_3316.c:1315)
>>> 11: a:1: ..adc[2] has 16 bits. (module/sis_3316/sis_3316.c:1322)
>>> 10: a:1: ..adc[3] firmware=0x0125a012. (module/sis_3316/sis_3316.c:1315)
>>> 11: a:1: ..adc[3] has 16 bits. (module/sis_3316/sis_3316.c:1322)
>>>
>>>
>>> We never had look at the firmware and also exchanged or six SIS3316
>>> modules for each other. Thus, my assumption is that differences in the
>>> firmware number should not matter. But of course, I am not sure about this.
>>>
>>>
>>> What puzzles me right now is the fact, that on the old system we get so
>>> much more output on the command line. On the new system it is just the
>>> SIS3316 firmware information and, for some reason, the threshold
>>> settings (out of a ton of various setting options for this type of 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, 23. Januar 2024 14:15:41
>>> *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,
>>>
>>> how about the lines '..adc[0] firmware=' ? The ADC FPGAs have a different
>>> image than the VME FPGA.
>>>
>>> Perhaps they were not present with the older software..?
>>>
>>> I do not know much about the SSI3316 firmware versions, but from the looks
>>> of it, we have at least three different ones at hand so far for the VME
>>> FPGA:
>>>
>>> 0x3316200e, 0x33162010, 0x3316a012
>>>
>>> Best regards,
>>> Håkan
>>>
>>>
>>> On Tue, 23 Jan 2024, Weber, Guenter Dr. wrote:
>>>
>>>>
>>>> Dear friends,
>>>>
>>>>
>>>> attached please find the output of the old system. To me it looks as if
>>>> every single setting of the SIS3316 modules is printed to screen. In total
>>>> almost 2000 lines for just two modules.
>>>>
>>>>
>>>> I find the following serial number entries:
>>>>
>>>>
>>>> Line 701:
>>>>
>>>> 10: a:1: ..Serial number=0x00800172. (module/sis_3316/sis_3316.c:1305)
>>>> 10: a:1: ..id/firmware=0x33162010. (module/sis_3316/sis_3316.c:1312)
>>>>
>>>>
>>>> Line 796:
>>>>
>>>> 10: a:1: ..Serial number=0x00800170. (module/sis_3316/sis_3316.c:1305)
>>>> 10: a:1: ..id/firmware=0x3316a012. (module/sis_3316/sis_3316.c:1312)
>>>
>>>
>>>
>>>
>>>>
>>>>
>>>>
>>>> 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, 23. Januar 2024 12:32:50
>>>> 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,
>>>>
>>>> On Tue, 23 Jan 2024, Weber, Guenter Dr. wrote:
>>>>
>>>> > 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.
>>>>
>>>> Could you for the other DAQ system (with working SIS3316), check the
>>>> output at startup or module re-init corresponding to these lines:
>>>>
>>>> 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.
>>>>
>>>> 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.
>>>>
>>>> and see what versions those modules have loaded?
>>>>
>>>> Cheers,
>>>> 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>
>>
>
More information about the subexp-daq
mailing list