Linux CVBpy Camera Mac Address/Unique ID

Programming Questions
1

Hi everyone,

I am working on an Ubuntu 16.04 system and have been interfacing with Genie Nano cameras with CVBPy. I have to work with four such cameras in the end and I would need to handle communication to and from a common application to these cameras. I am looking to somehow identify these cameras uniquely. Is there a way I can access the Mac Address of the camera with the help of CVBPy? I assumed that there might be such info inthe CVB.Device class however unfortunately there isn’t. Do any of you have an idea if this is possible?

Thanks

2

Hi @xenonforlife,

This topic (Getting Started with CVBpy) shows how to access the camera nodemaps via CVBpy.

All cameras should have the nodes “DeviceID” (with Dalsa the serial number) and “DeviceUserID” (a string set by the user).

This is one way to diffentiate cameras from each other.

Hope this helps.

Christopher

3

Further more:

I just check “my” Nano. And there is a node called: “deviceMacAddress” (Namespace Custom).

Cheers,

Christopher

4

Hi @c.hartmann,

I did try the procedure outlined in (Getting Started with CVBpy), but somehow it results in an error when I am trying to access the NodeMap of the device. Are you sure that the functionality is available in the Linux version of CVBPy too? The reason I am asking is that I am not being able to access the node_maps array from the Device object (maybe it has been declared private?). I still went ahead and tried to access the node_map array (assuming that maybe it is an intellisense error) but ended up in errors. Here is my code, it’s fairly similar to the Getting Started guide but for me I get a runtime error.

import os
import cvb
import numpy

# choose your driver
device = cvb.DeviceFactory.open(os.environ["CVB"] + "/drivers/GenICam.vin")
device_node_map = device.node_maps["Device"]

Here is the runtime error:

Traceback (most recent call last):
  File "/home/test_user/Desktop/LocalPythonSendReceiveImageJson/PyAcquireStream.py", line 9, in <module>
    device_node_map = device.node_maps["Device"]
RuntimeError: failed to get node map
5

Hi @xenonforlife,

as I posted in another thread this ought to be a bug and we will check this on the Linux platform (it is working under Windows).

Regarding the features for identifying devices
(all from the Standard Features Naming Convention document):
DeviceID is now deprecated by the GenICam SFNC (Standard Features Naming Convention). You should only use it as a fallback for DeviceSerialNumber (they renamed DeviceID to DeviceSerialNumber). This, though, is not unique on its own. If you want a vendor and technology agnostic identification scheme you need:

  • DeviceVendorName
  • DeviceModelName
  • DeviceSerialNumber

These three toghether uniquely identify a device.

As @c.hartmann pointed out DeviceUserID is an easier way to identify a camera based on your purpose. You can put something like PartA or TopLeft into it. This also makes it easier to exchange cameras later on and precofigure them based on its purpose.

Of course you can also use technology dependent identifiers like GevMACAddress, which is equivalent to DeviceVendorName, DeviceModelName, DeviceSerialNumber.

Which scheme to choose?
If you want it to be done manually by an operator on-site I would choose the unique identifier approach. You can do this e.g. via camera numberings (port 0 to n) by configuring this with the GenICam Browser. Or by using the new discovery interface inside you application.

If you want to preconfigure the device in your lab and simply exchange the devices on-site I would prefer discovery interface and DeviceUserID.

On Linux I would prefer preconfiguration with the GenICam Browser until :cvb: 13.01.xxx is released.

6

Hi @parsd,

this was indeed extremely helpful information, I will keep it in mind while finalising which strategy to use for our particular project.
Thanks again for the insights,

7

Works flawlessly now with the newest library :slight_smile: Thanks for the updated library!

8

And thank you for your feedback. Glad everything works fine now!