DAQmx API event to detect USB device hot plugged in

[sradbil]

Using the DAQmx API calls, is there a way to request notification to detect when a USB device has been plugged in to the PC?

I found  information on registering callbacks for Done, Signal and EveryNSamplesEvent (e.g. DAQmxRegisterDoneEvent, DAQmxRegisterSignalEvent and DAQmxRegisterEveryNSamplesEvent) but nothing like "DAQmxRegisterDevicePluginDetectedEvent".

The ends of these threads:

http://forums.ni.com/ni/board/message?board.id=250&message.id=28298&requireLogin=False

http://forums.ni.com/ni/board/message?board.id=170&message.id=245864&query.id=69454#M245864

make it look as though I'm going to have to poll for all devices with:

DAQmxGetSysDevNames(char *data, uInt32 bufferSize);

but I'm hoping that there is something more automated available.

All ideas and points appreciated. 

Thanks. 

[Christian Mergl]

Hey,

DAQmx does not provide such an event.

You can try to get the event which is produced by the operating system if you plug in a USB device.

Christian

[sradbil]

Hello again,

I'm working on Windows and have a program that uses the standard Windows WM_DEVICECHANGE message and others as described in the MSDN Device Management Reference http://msdn.microsoft.com/en-us/library/aa363239(VS.85).aspx

When I plug in a single device it is detected. This is expected and is good.

When I plug in a cDAQ-9172 CompactDAQ chassis it is detected. Also expected and good.

But when I plug individual modules into the cDAQ chassis there is no Windows operating system event generated so the new module is not detected. This is the problem.

In Measurement and Automation Explorer the module appears in the chassis instantaneously.

Please let me know what the mechanism is that I need to use to detect CompactDAQ module plug in and unplug.

Thanks,

[Jordan F]

The cDAQ modules are all hot swappable so the behavior of seeing the modules in MAX when placing them in the chassis is expected.  After looking into the Device Management Events on the Microsoft website, that only will work if you plug in a device directly to the computer such as usb.  The devices that are added to the cDAQ chassis will not trigger a windows event unless you recycle the power on the chassis or unplug/plug the chassis.  The advice of polling what devices are in the cDAQ chassis in your program would be the best way to know the current status of the chassis.   

Is there a specific reason that you need a windows event generated when modules are added or removed? 

[sradbil]

Hi Jordan,

Thanks for the answer.

So are you saying that  MAX is constantly polling the chassis to instantaneously detect the CompactDAQ module plug in?

I was hoping for a DAQmx event that arrives when a CompactDAQ module is plugged in or unplugged from the chassis

For instance, something similar to DAQmxRegisterSignalEvent that would allow me to register a callback for CompactDAQ module insertion/removal events.

I don't necessarily need a Windows event.

Our application can detect USB devices plugged in using the Windows events and now we need to ensure that it detects CompactDAQ modules as well. I prefer not to poll so other suggestions are welcome.

All the best,

[Jordan F]

Hi Sherryl,

The only way currently to see what devices are in your chassis is to poll the device names (ex. DAQmx Device Property Node->Chassis.ModuleDeviceNames).  There is no event triggered because the individual modules are not detected by Windows, the chassis is what controls all the communication (hence why you can receive an event when the chassis is added).  I am unsure how exactly the modules are detected by MAX so I can look into this futher for you. 

I know that polling is undesired but it will not take up too much CPU usage if you only poll the chassis every half second or second.  Again, this is the only way to have your program detect the available devices.       

[sradbil]

Hi Jordan,

Thanks for this information.

If you could find out how MaX does it and post back to this thread that would be extremely helpful.

Best regards,

[Brad_K]

Hi Sherryl,

The cDAQ chassis driver notifies MAX of module insertion/removal in an event-driven manner, but this is not related to the event functionality that is exposed through the NI-DAQmx API. The NI-DAQmx API does not expose this information as an event, as has been stated; it only allows you to query which devices are currently installed.

I agree that it would be nice if WM_DEVICECHANGE worked for cDAQ modules (as well as Ethernet/wireless DAQ and SCXI), but it does not because these devices are not managed by Windows. If you only need this functionality for cDAQ and not Ethernet/wireless DAQ and SCXI, then you could use WM_DEVICECHANGE to enable polling (in a separate thread) when a cDAQ chassis is detected, and disable it when the cDAQ chassis is removed.

I recommend submitting product feedback about this use case at ni.com/contact.

 

Brad

[MarkGrot]

With DAQmx 9.0 you should now be able to use WM_DEVICECHANGE to detect when a cDAQ module is inserted/removed.  As stated elsewhere in this thread, this will not work on previous versions of DAQmx.

This will not work for modules in a USB-9162 or Ethernet/Wireless 9163 carrier.

Message Edited by MarkGrot on 08-06-2009 03:58 PM

[sradbil]

WM_DEVICECHANGE works well with DAQmx 9.0 but the CompactDAQ modules give a different vendor ID in the plug and play broadcast message dbcc_name field than the vendor ID given by USB devices.


(see documentation for dbcc_name in the DEV_BROADCAST_DEVICEINTERFACE Structure here:
http://msdn.microsoft.com/en-us/library/aa363244(VS.85).aspx)

For instance, when inserting or removing a USB device, say USB-6211, the dbcc_name is:

\\?\USB#Vid_3923&Pid_7269#5&accb944&0&6#{2599561a-ef61-44a2-9e7c-82046945fcc2}"
 

Notice that the vendor ID (VID) is 3923.

With a USB-6218 we get:

\\?\USB#Vid_3923&Pid_7272#01387907#{2599561a-ef61-44a2-9e7c-82046945fcc2}

 VID is 3923

 
For the cDAQ-9172 itself the string is

\\?\USB#Vid_3923&Pid_715e#0126F5F6#{a5dcbf10-6530-11d2-901f-00c04fb951ed}

Again here the VID is 3923.


But when inserting/removing CompactDAQ modules from the chassis, say the NI 9264, the

VID is 1093.

"\\?\{5e9419d9-6dde-45bd-81e3-03eb116c8ad5}#VID_1093&PID_72c3&CDAQ_9172&Bus_USB#01351358#{5312f5bb-8f99-4e18-b464-1a0a845fc4cb}"


The string for the NI 9205 is:

\\?\{5e9419d9-6dde-45bd-81e3-03eb116c8ad5}#VID_1093&PID_7265&CDAQ_9172&Bus_USB#0126ff7a#{5312f5bb-8f99-4e18-b464-1a0a845fc4cb}

Again, VID for this cDAQ module is 1093.

 I expected the vendor ID for all NI devices to be the same whether they are USB devices or cDAQ modules.

Our code that handles plug and play decides what to do based on the vendor ID and if NI devices return differing vendor IDs this complicates the code.

Questions:

1. Why is the vendor ID different for USB devices and cDAQ modules?

2. Does other NI hardware have yet more vendor IDs and if so can we get a list of the vendor IDs that NI hardware will return?

Thanks for adding the functionality, and thanks in advance for any information you can provide about the vendor ids!