Finding USB Device

[jyang72211]

Hi all,

I have a USB-6008 that plugs in directly to a PC.  I am building a box, which has the 6008 in it, for a customer, and I will give them a labview exe as well.  The exe will control the 6008. 

When the 6008 plus in to the customer's PC, the 6008 could be dev1, dev2, dev3, etc, depending on how many devices are connected to the customer's PC.  My labview program has to know the device name to operate correctly.  How can I implement search routine that would find out what the 6008's name is on the customer's PC?  If this is impossible, how do I make the options in the device name control more descriptive?  Thanks!

 BTW, for the dashboard in the discussion board, how do I clean up the topic that I previous posted?  The dashboard says that i have 2 more pages, but I can get to the rest of the pages.  How do I do that?

Yik

[MarkGrot]

You can use the DAQmx System property node to query all device names in the system.  If you feed those into a loop with a DAQmx Device property node, you can query the Product Type, Product Number, Serial Number, etc for the device.  You can use that to find your specific device.

[mallorim · Accepted solution]

Hello Yik,

I built a quick VI for you illustrating some of what my coworker said. Basically, you use a System Property node, found on the Functions Palette by navigating DAQmx>>Advanced>>System Set Up>>System Property Node. The Property you want to use is Dev Names. This will return a list of all the DAQmx device names on the system. Now, if you run these through a for loop, you can use a DAQmx Device Property Node to read the identification information for that device. Right click on the for loop border and add a Conditional Terminal to the for loop, this will let you exit the loop when you find the device you want. You can then use the concatenate strings function to add the desired channels to your device name, and then you are good to go. I have attached the example below.

Now it is up to you how you decide you have found the right device. While you can search for the Product Type like I have in the VI, a problem arises if your customer is likely to have more than one USB-6009 in their system. This program will stop at the first one it finds, and if that is not yours, you have problems. Instead, it might be useful, if you know the unique serial number of the device you are building into your box, it might be better to use this to identify the proper device. Serial number is another Identification property.

Regards,

Mallori M.

[mallorim]

Hi Yik,

All this built code aside, I think we are missing the forest for the trees. The best solution to this problem would be to type instructions on the front panel of your executable telling your customer how to open MAX and identify the poroper DAQmx resource name for the USB-6009. They can then select that from the drop down Physical Channels list and you no longer have to hardcode in serial numbers or worry about multiple USB-6009s. A customer should be able to do that...

Regards,

Mallori

[Tom__Sedlack]

Mallori,

With all due respect, I believe your way would be the last possible way to do this.  If a customer is paying for a system, I would assume they are paying for a system that they turn on and use, not turn on, configure, hope they picked the right module, and then use.  Think of how you might get frustrated when adding a peripheral card to a PC and everytime you turn the computer on, you need to configure the card.

I've built systems that use USB DAQs and DIO and have seen this issue; is it dev1? dev2? I keep a list of the serial numbers in an .INI file which then associates the fixture.  The test software queries the fixture USB module for the serial number, looks in the .INI file to find out what fixture is connected and what modules it can test, then loads the proper code.  A customer is going to be much happier if they do not need to deal with all behind the scene hardware stuff.

Tom

[mallorim]

Hi Tom and Yik,

I was intrigued by the problem statement and built the VI I attached in my first post and then sat back and thought "Man, that was a lot of work for what could be accomplished by merely opening MAX and checking." This thought was the reason for my second post. Being a DAQ supporter for a number of years, I have become quite familiar with Measurement and Automation Explorer (MAX), understanding the configuration tree at a glance is now second nature. I also thought that someone with muliple NI Cards on their system would most likely already be familiar with MAX. All of these thoughts contributed to my second post.

I can see though why this might be undesirable in an out of box customer solution, in which case my first post and that VI would be ideal. I do like your idea of a .ini file with all of the serial numbers. As someone who does not build customer solutions, this was not something I initially thought of, though I can see the wisdom of it. This would work much better than hardcoding a serial number in a constant and could be easily implemented with a file I/O operation.

Regards,

Mallori

[jyang72211]

Thank you, mallorim.  This is exactly what I am thinking. 

Yik

[karthick]

thank u for ur code...