get_board_number() returns -1 for a DaqDeviceDescriptor returned from get_daq_device_inventory()

[mccdaq]

get_board_number() returns -1 for a DaqDeviceDescriptor returned from get_daq_device_inventory()

[dlebelcimmi]

We are also experimenting the same issue with the USB-2416 device. This seems to me like a quite severe issue since we can't get board_number dynamically where big part of the api depends upon a board number. Thank you to consider addressing this issue.

[jeffreyg3]

you get that result because no devices were found or instantiated.

Please review example a_in.py

You are trying to get the board number of the device before you have created an instance of the device.

in short, you need to call this:
daq_device = DaqDevoce(devices[array_index])
before you can call:
print(ul.get_board_number(daq_device))

[dlebelcimmi]

Thank you for your answer,

Unfortunately I don't think this solves the issue.
I am not sure at what api you refer to. A search for DaqDevice returns nothing in the documentation. Nor in the a_in.py example (or I didn't found it)

Summarizing the example, it does:
ul.ignore_instacal()
devices = ul.get_daq_device_inventory(InterfaceType.ANY)
...
ul.create_daq_device(board_num, device) # I suppose that's the line you refer to with DaqDevoce(devices[array_index])

Then at that point I would be able to do a ul.get_board_number(device). Yes that works and I tried it. But this is not the same use case and I should have specified it earlier. This case uses the ul.ignore_instacal() so you need to create your own device library. The documentation says about ignore_instacal() :

Prevents the Universal Library from automatically adding a DAQ device has been stored in the cb.cfg file by InstaCal. This function must be the first Universal Library function invoked in the application.

But what if we precisely want to use the instacal library. This is the use case I am referring to. If we don't call ul.ignore_instacal(), we can configure the device and operate it. By providing the board number, everything works fine. So the board number exist somewhere that the api knows of how to associate it with the specified board. Except that calling ul.get_board_number(device) returns -1 even though we didn't call ul.ignore_instacal()

By the way, I can confirm that it is doing the same either with USB-2416 and also USB-2404ui.

[jeffreyg3]

My bad, I was thinking Linux version of UL library (uldaq), but you are running UL for python on Windows (mcculw).
but no matter.
Why are you trying to return the board number? this is something you set so you already know what it it is.

this line:
ul.create_daq_device(board_num, device)
is what sets the board number.

I still recommend you step through one of the installed examples such as a_in.py and console_examples_util.py so you can see how the device object is created.

I edited the console_examples_util.py by adding ...

print('board num:')
print(ul.get_board_number(device))

...at the end of the existing code. It returns the correct value. But as stated, since board_num is a variable set in a_in.py, you already know what it is going to be.

I modified a_in.py, line 38 to:
board_num = 5

so when I run the example, it prints:
board num:
5

The complete example print out is:
Found 1 DAQ device(s):
USB-2416 (87745) - Device ID = 208
board num:
5

Active DAQ device: USB-2416 (87745)

Raw Value: 8388645
Engineering Value: 0.000

Process finished with exit code 0

the example is installed in your C:\Users\Public\Documents\Measurement Computing\DAQ\Python\examples\console

[dlebelcimmi]

Yeah, sorry for that, I should have specified I'm on Windows.

I understand the examples and I am already creating my own device registry doing the same as the example. And it is working. The issue is that I don't think I should have to build my own registry and this is due to the issue I am talking about. Let's say there are 2 main use cases dealing with device registries:

1. Building your own registry
2. Using the instacal registry (CB.CFG)

Use case # 1
This use case is the one demonstrated in the example and the one I am currently implementing because of the current bug. I have no issue with this one, it is working. This use case implies to call ul.ignore_instacal() as the first call of the api. here is a prototype of this use case:

ul.ignore_instacal() #tell the api to ignore instacal registry
devices = ul.get_daq_device_inventory(Interface.ANY) # get the devices
arbitrary_board_number = 0
ul.create_daq_device(arbitrary_board_number, device[0])

ul.set_config(..., arbitrary_board_number, ...)
ul.do_some_other_stuff(..., arbitrary_board_number, ...)
...

Use case # 2
This is the scenario that seems to me having an issue. Here is its prototype:

#### No call to ul.ignore_instacal() meaning we want to use instacal registry###
devices = ul.get_daq_device_inventory(Interface.ANY) # get the devices
instacal_board_number = ul.create_daq_device(device[0])

ul.set_config(..., instacal_board_number, ...)
ul.do_some_other_stuff(..., instacal_board_number, ...)
...

As said before, the documentation sais about ignore_instacal()

Prevents the Universal Library from automatically adding a DAQ device has been stored in the cb.cfg file by InstaCal. This function must be the first Universal Library function invoked in the application.

In this case, we do not attribute the board number ourselves. The file CB.CFG holds the catralog of devices associated with board_numbers. If we hard code the board_number, then we can operate the device EVEN without calling create_daq_device(). This means that the registry is known to the api. The only line that is not working in this scenario is get_board_number(). The issue is that get_board_number(device) wrongly returns -1 even though the device is in the instacal registry. Since ul.ignore_instacal() was not called, it should return the board number according to the CB.CFG file.

I hope that it clarifies things.

Thank you!

[jeffreyg3]

I don't know as I would call what is in cb.cfg a 'catalog' exactly.
This used to be required prior to having device discovery functions in the UL.
much of what you are referring to is there because we wanted to make the customer experience with our examples better. Our examples did not always work 'out of the box,' changes to range, rate, etc would need to be made. So extra levels of information were added along with device discovery function.

How about this (a more direct access to the device)...

a_in_w_CBcfg.zip

[dlebelcimmi]

hmm, you don't seem to want to recognize that as an issue. To me this is a broken flow. There is a method called get_board_number() that says it "gets the board number" but doesn't get the board number when ul.ignore_instacal() is not called. This is a method that does not do what it says. Maybe it is working as designed. Then I would find that rather weird. Anyway, I am making my own registry.

That was my last comment on that issue. I was not the one who opened that issue so at least two users found that problematic. I hope other users will back me if they share my opinion.

Thank you for your time.

[linuxrider]

Unfortunately, I had not enough time lately to comment on this issue.
Thank you very much @dlebelcimmi! You brought up exactly my arguments!
@jeffreyg3
If get_board_number() is not intended to work with the instacal configuration I would really appreciate if this could be documented.
Thank you.

[dlebelcimmi]

Thanks @linuxrider !
By the way, personally I would not close this issue. If other users meet the same issue they will comment on the thread. I would rather let MCC decide whether they agree to see it as a bug or if it is behaving as intended. They would close it themselves providing their conclusion.

[linuxrider]

Thanks for the hint!