Need to pull out/re-insert the USB cable for the device

[MCC007]

Envirnoment
Windows 7 64bit (Professional)
Drivers 2.1.8 (March 29 2011)
Using PhidgetInterfaceKit 7.0.
Using InterfaceKit-full.exe in the 'C:\Program Files\Phidgets\Examples' folder
Serial Number 109943
Version 707

Issue
I run the application and it does not report anything about the Interface (e.g. version). I remove the USB cable re-insert it and it see everything and it all works.

If I shut down and relaunch the app before 3 minutes of re-inserting the USB cable all is OK. Any longer and I am back to it not 'seeing' the interface

[erik]

Are there any other programs running that could be trying to connect to the InterfaceKit? Only one program can access the Phidget at a time, and any other programs will be blocked from getting any data from it.

[MCC007]

I checked the system tray and the Phidget Control Panel is not running and no other program is running. Are there any logs I could start to determine what might be occurring

[miks]

I got similar problem with Windows 7.
If computer get switched off and then on with pfidgets plugged in, "PhidgetInterfaceKit 0/16/16" is not recognized through phidgets control panel. After pull out/re-insert everything is working fine.
Could there be some problem in computer USB settings other than phidget device itself?

[MCC008]

I came back to this issue and am having the same problem. I downloaded the framework Phidget-x64_2.1.8.20111121 for the Windows 7 64bit Professional Machine. The programs I am running are all from the samples and include the sample InterfaceKit-full.exe. I also downloaded the VC InterfaceKit-simple sample, compiled it for both x64 and x32 and all have this problem.

All is OK if I run the application quickly after inserting the USB cable. If I wait, the device is not seen. I am not running a Logitech Mouse.

If you send me some contact information, I can get you attached to a development machine which is showing this problem and you will see the problem in about 3 mins.

[Patrick]

Hi,

If you can enable logging in one of the sample applications and then run it until the disconnect happens and send us the log, we can at least determine the cause.

For example, in C#, add before any other Phidgets calls:

Phidget.enableLogging(PHIDGET_LOG_VERBOSE, filename);

-Patrick

[MCC008]

Patrick

Thank you for looking into this. I have updated the files as requested. The good.log was the first run, while the bad.log is the next run. I can see the ERROR_SHARING_VIOLATION - probably the Phidget is opened elsewhere. but I am not sure what has got hold of it.

Thanks in advance

[Patrick]

This is definitely caused by some other program opening the Phidget.

We have seen this behaviour from Nike's Nike+ software, and Also some logitech webcam software. There may be others - can you think of any third-party software on your computer that's related to USB devices?

This is generally caused when these other companies just try to open every USB HID device, even if it is not their device - bad coding.

-Patrick

[MCC008]

Patrick

Thank you for looking into this more deeply. While waiting I started to go through my system and I resolved the issue by apply the latest driver to the Smartworks board. This board is made by AudioCodes and to be honest I was surprised this to be culprit as it does not have a USB interface.

All seems to be good at the moment and I will contact you if I run across any other issues.

Thank you once again

[ghell2000]

If I well understand this bug wil never be solved!
When a door is left open to anybody, who is to be blamed?
The people who enter or the people who let the door widely open?