Measurement Studio for VC++

cancel
Showing results for 
Search instead for 
Did you mean: 

DAQmxGetDevSerialNum in Win 7

When I use DAQmxGetDevSerialNum on my XP system it works properly in my Visual Studio 2010 C++ program. However, on my Win 7 program in Visual Studio 2010 C++ it returns error=0 even when the NI-DAQ USB-6259 is not plugged in. Measurement & Automation shows 'Dev1' as grayed out, correctly, but the C++ program returns 0 with a bogus serial number.

 

Is there any issue running in Win 7?

 

Thanks,

Brian

0 Kudos
Message 1 of 7
(4,887 Views)

Further note, I'm not using Measurement Studio. I'm writing C++ in Visual Studio 2010 and using the NiDAQmx-9.4 library on both Win 7 and XP. Before migrating to Visual Studio 2010 on Win 7 I was using Visual C++ 6.0 on an XP machine and using NiDAQmx-9.02 drivers.

 

It seems to be working on the XP OS but not Win 7.

 

Thanks,

 

 

 

0 Kudos
Message 2 of 7
(4,885 Views)

A little more info. As I said, on Win 7 in Measurement & Automation it shows Dev 1 as grayed out when the USB-6259 is off or unplugged. If I run my C++ program the function call returns with error 0 and a bogus serial #. However, if I delete the device in Measurement & Automation and then run my C++ program the function returns with error -200220 as it should.

 

Thanks,

0 Kudos
Message 3 of 7
(4,882 Views)

Hi btremaine,

 

When you say it is still working on your XP system, is that XP system still using the DAQmx 9.02 drivers rather than the DAQmx 9.4 drivers?  I am not very familiar with how the devices are stored in 9.02, but in 9.4 the device information is stored persistantly.  So when the DAQmxGetDevSerialNum is called on a device that is not currently plugged in, but is still registered in the system, it will return the correct serial number of the device.  I was able to test this myself, and I received the correct serial number when calling the function from both XP and Windows 7.  However, my experiment was done using DAQmx 9.4 and not 9.02.  Could you verify that it is a bogus serial number you are receiving, it may be formatted in binary rather than HEX?  Also is there a reason you are expecting it to return error -200220?  This error indicates that the device identifier is invalid and not that the device is disconnected from the system.

Justin D
Applications Engineer
National Instruments
http://www.ni.com/support/
0 Kudos
Message 4 of 7
(4,867 Views)

Both the XP and Win 7 platforms are running 9.4 NiDAQmx drivers. I think I understand the problem a little better now.

 

It appears as you say that with 9.4 drivers the device information is persistent on both the XP and Win 7. And yes you are correct what I thought was a bogus serial # is really the value in decimal and not hex.

 

With that said, when running the 9.02 drivers I was using the DAQmxGetDevSerialNum function to tell whether the device was plugged in and ready. In 9.4 since the data is persistent this no longer works.

 

Can you suggest a good method to determine if the device is plugged in and ready?

 

Thanks,

Brian

0 Kudos
Message 5 of 7
(4,861 Views)

Hi btremaine,

 

The active devices in the system may be accessed from a property of the DAQmx System.  To get a list of the devices connected you can use the function DAQmxGetSysDevNames.  This function will return a list of the device identifiers for the currently usable devices.  If you know the identifier of the device you are looking for you can simply compare each identifier name to see if that device is found, or if you are trying to verify the device by the serial number you can use each of these device identifiers to query for a serial number and go from there.

Justin D
Applications Engineer
National Instruments
http://www.ni.com/support/
0 Kudos
Message 6 of 7
(4,854 Views)

Thanks, I took your advice and am using  DAQmxGetSysDevNames and searching for the expected device name. When the device is off or unplugged I now detect the error (even though DAQmxGetDevSerialNum still returns the persistent serial number).

 

Regards,

Brian

0 Kudos
Message 7 of 7
(4,849 Views)