LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Problem differentiating between two identical USB cameras

Hi YaTinM,

Thanks for the advice. I followed your link to the forum covering registry edits, and was a little alarmed to read how unstable it can make the system. In fact, referring to my previous posts, using the DevCon from Microsoft to disable/enable the cameras also causes severe system instability, and quite often WinXP will reboot without warning, then state it has recovered from a serious error. And this is after using a Microsoft approved program to play with the devices! Smiley Very Happy

Unfortunately our experiment set-up precludes the use of anything other than the cameras we have. We're installing
miniature cameras in a rotating rig that are then subjected to 600 G, they have to be encapsulated and data communication must be USB due to the limitations of our slip-ring Smiley Sad So sadly we're stuck with them.

We also have further cameras outside our experiment which are of a different manufacturer and indeed Firewire, and as such these cameras do not present a problem. It's just the issue of distinguishing between the two USB cameras that's frustrating.

We're still hoping someone out there has managed to circumvent this identical filter name issue without having to hack the registry. Other software applications can identify the two cameras independently, so we're optimistic that it must be possible also with LabVIEW. Has anyone out there any knowledge of interfacing the Windows USB drivers in more detail than currently provided within the LabVIEW USB vi's ??


Thanks again for your input YaTinM

0 Kudos
Message 11 of 17
(2,485 Views)

There should be some registry values somewhere that give each camera a unique id number. Maybe the manufacturer can tell you where it is located. Could the slip ring position be checked and then compare the image from each camera to an expected image?? Then you could determine which camera is first or second.

Maybe these links will provide some info.

http://msdn2.microsoft.com/en-us/library/ms791870.aspx

http://msdn2.microsoft.com/en-us/library/ms791877.aspx

http://www.microsoft.com/technet/prodtechnol/winxppro/reskit/c09621675.mspx

Message 12 of 17
(2,483 Views)
Hi unclebump,
 
It seems I'm way out of my depth now. I looked in the registry (regedit) and searched for each occurance of "Videology USB camera", which is the string result from IMAQ USB Enumerate cameras.vi. This found many entries, each with a handful of surrounding registry entries, including DriverDesc, which seems in all cases to contain the exact string reported by LabVIEW (ie Videology USB camera). I attempted to change the content of this string for each search result to alter its identity, but this hasn't worked. For half of the search results the string name change had no impact, and for the rest RegEdit failed to change the string. I am too unfamiliar with editing registries. I'm afraid I really do not know what I'm doing (I suspect I'm lucky not to have crashed WinXP here!).
 
Also, I cannot understand the complicated content of the links you included in your last post. I'm not an expert in these things and don't know what "ICM profiles" nor "ISIS driver name" mean, for example. Smiley Sad
 
Many thanks for your help so far, I hope I can get there in the end Smiley Wink
0 Kudos
Message 13 of 17
(2,478 Views)
Update:
We've played a bit more with the registry. It seems that if we edit the "FriendlyName" string for one particular camera throughout the registry (each camera appears in about five or six different distinct categories) then LabVIEW sees the new names when it enumerates the cameras. This would be great, but it crashes WinXP with a 'serious error'. Furthermore, this test only works with the two cameras are plugged into two different USB ports on the back of the PC. In the rig, we will have the two cameras on a USB hub that itself is connected to only one USB port on the back of the PC. In this configuration, camera 1 fails to respond at all. This could be a separate issue related to the hub, which we need to investigate.
 
Thanks for everyone's input, but I think we're screwed (thanks to Microsoft's inability to distinguish between identical devices on different ports).
 
Riggy.
0 Kudos
Message 14 of 17
(2,468 Views)
Maybe you can use some remote USB devices that connect to an ethernet network. Put two of these out there instead of one hub.
 
Message 15 of 17
(2,461 Views)
We'd already considered these options thanks, but we require the full 400 Mbps data rate of USB 2.0, all devices we could find that converted USB to another format reduced the data rate, as do the products you found. They all have a maximum data rate of just 12 Mbps. Smiley Sad
We even bought the world's first wireless 'broadband' USB 2.0 hub from Japan when it came out last year, with full-speed data rates of 400 Mbps. Unfortunately it didn't work with webcameras! Smiley Mad That was quite disappointing because it cost a lot of money, time and effort to get it imported. Smiley Tongue

Thanks for trying to solve our problems for us unclebump, you're very dedicated! Smiley Happy
0 Kudos
Message 16 of 17
(2,450 Views)
Did you ever find a resolution to this problem?  I have interest in the same type of application, but dont know that much about USB drivers..
0 Kudos
Message 17 of 17
(2,054 Views)