Hello,
Our Jungo Windriver based driver uses WDU_Init to be notified of supported instruments. Our handler follows their example code. In most situations it works. But we have detected two situations with the following symptoms : the device is assigned a Jungo driver by windows which can be seen in the device manager but we never get the attachment interrupt. We have seen this on Windows 7 32, Windows 7 64, and Windows XP (I don't now if that was 32 or 64 bit). One situation that exhibits the symptoms is we have our application started it has already called WDU_Init which it only does once and we turn on a device that was already attached to the USB port but not turned on. This problem is rock solid we NEVER get the interrupt until we physically unplug the USB cable and plug it back in. Or until we exit our software and re-start it. We did try one experiment where we repeated the WDU_Init but that did not help. This is the situation we require a fix for most urgently. The other situation happens, we think, when code causes the device's buffer to be full. In that situation re-starting our software does not remedy the situation. The same basic problem occures : Windows assigns the driver but we never get the attach interrupt.
Has anyone here seen similar behavior? Is there a fix or a work around?
Thank you,
Chas
Our Jungo Windriver based driver uses WDU_Init to be notified of supported instruments. Our handler follows their example code. In most situations it works. But we have detected two situations with the following symptoms : the device is assigned a Jungo driver by windows which can be seen in the device manager but we never get the attachment interrupt. We have seen this on Windows 7 32, Windows 7 64, and Windows XP (I don't now if that was 32 or 64 bit). One situation that exhibits the symptoms is we have our application started it has already called WDU_Init which it only does once and we turn on a device that was already attached to the USB port but not turned on. This problem is rock solid we NEVER get the interrupt until we physically unplug the USB cable and plug it back in. Or until we exit our software and re-start it. We did try one experiment where we repeated the WDU_Init but that did not help. This is the situation we require a fix for most urgently. The other situation happens, we think, when code causes the device's buffer to be full. In that situation re-starting our software does not remedy the situation. The same basic problem occures : Windows assigns the driver but we never get the attach interrupt.
Has anyone here seen similar behavior? Is there a fix or a work around?
Thank you,
Chas
Facebook
Twitter
Instagram