Device naming convention?

[thricedaily]

I am assembling a data acq system that will have 2 or 3 USB-6009 units connected to a Mac (Intel) running OS X. Based on my observations connecting and disconnecting two different USB-6009's and checking the assigned device names in Isdaq.app, it looks as if "Dev1", and "Dev2" are assigned based on increasing serial number. E.g. The USB-6009 with serial number 1256A9A would always be assigned "Dev1" and the USB-6009 with serial number 1256A9B would always be "Dev2" (regardless of which one is connected first). Of course I understand that if only 1 unit is present then it will be assigned "Dev1".

Is it safe to assume this will always be true? FYI - I am using NIDAQmx Base 2.1.0 and my own C code (no LabVIEW).

[devchander]

That would not be a safe assumption 

Device number assignment would be dependant on the order in which you bring in/connect cards to the PC rather than on the serial number.

[thricedaily]

No matter what order I connect the two USB-6009's, the one with the lower serial number always is assigned "Dev1". Does anyone know for sure if there is a rule that is followed? It certainly isn't based on connection order (at least on my OS X computer).

[Jesse_O]

Hello,

I just ran some tests on an Intel Macbook Pro.  When you plug in a single USB-6008/9 it will become Dev1 in lsdaq.  When you plug in a second USB-6009 you will have Dev1 and Dev2 in lsdaq.

The order they appear in does not depend on the order you plugged them in or their serial number, it depends on the port used.  For example the Macbook Pro has two USB ports, one on the left and one on the right side of the laptop.  Whatever device I plugged into the port on the right became dev1.  This is the same behavior I see on a windows machine with DAQmx Base.

In your setup I assume you see that the lowest serial number device always became Dev1 because of where you plugged it in.  If you switch the ports of the two 6009s, the higher serial number device should become Dev1.

Regards,

Jesse O.
Applications Engineering
National Instruments

[thricedaily]

I see. I verified that behavior on my MacBook Pro. Thanks, that solves that problem.

Now here is the more difficult follow-up question: What happens when I use a USB hub? I know that it is not recommended to use a hub, but I am doing very low-speed data acquisition and will be using a powered USB hub. From my experimentation it seems like "Dev1" is always the first device to be plugged into the hub (regardless of which port I plug it into). If I power up my computer with mutiple USB-6009's already connected to the USB hub, I do not get the same Dev-numbers assigned to the units every time.

[Jesse_O]

Hello,

Please correct me if I am wrong, but I believe your end goal is to determine which of your USB devices is Dev1 and which is Dev2.  Perhaps knowing the serial number of each would be better than just hoping they are plugged into the correct port by the user.  There is a DAQmx base VI called DAQmxBase Read Serial Number.vi that is part of DAQmx base.  It is not in the LabVIEW DAQmx palette but you can find in your LabVIEW folder here:  LabVIEW 8.2\vi.lib\_DAQmxBase\Internals\DAQmxBase Serial Num.llb\DAQmxBase Read Serial Number.vi

It will allow you to read the serial number in LabVIEW for your USB devices connected.  I hope this helps.  If not please let me know.

Regards,

Jesse O.
Applications Engineering
National Instruments

[thricedaily]

Hi Jesse,
  yes that is basically what I want to accomplish. But, I'm doing this all in C code without LabVIEW, so unfortunately that VI doesn't help.

[thricedaily]

It would be great if there was an equivalent function in NIDAQmx Base, but I don't think there is ?!?

[Jesse_O]

Hello,

Although the NI-DAQmx base C function help does not list the command, this function is exported in the dll header file.  I have tested it, and I was able to get the correct serial numbers back.  The c command is int32 DllExport __CFUNC DAQmxBaseGetDevSerialNum(const char device[], uInt32 *data);  You can see this in the header file around line 2415.


I hope this helps,

Jesse O.
Applications Engineering
National Instruments

[thricedaily]

Thank You Jesse, that is exactly what I was looking for.