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

Wed Jan 24 11:23:19 CET 2024

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