Slow IMAQdx v3.7 gige camera enumeration/connection

[BlueCheese · Accepted solution]

Hi pj325is,

The EnableIPCameras key should be a DWORD, not a string (I'm not sure why the EnableDirectShowCameras is not a DWORD as well).

The size of the network should not matter as the discovery time is constant per iteration.

Eric

[pj325is]

That did it!  Making "EnableIPCameras" a DWORD and setting its value to 0 makes camera enumeration and connection (both in MAX and vb.net code) as fast as they were in v3.2. 

I originally made "EnableIPCameras" a string value because "EnableDirectShowCameras" is a string, so I'm not sure why it is like that if it's incorrect.  Both of my systems with v3.7 have "EnableDirectShowCameras" as a string.

This solution is satisfactory to me since I'm not using IP cameras, but if you want me to try anything else that could help further pinpoint the cause of the slowness with IP cameras enabled, let me know.

Thanks for the help.

[BlueCheese]

The string value for EnableDirectShowCameras appears to be a bug in the installer. It ends up not mattering because the driver has its own default values which match the default values put down by the installer.

I'm a bit surprised that the IP camera thing fixed it, as it would point to some issue with the multicast DNS resolver that is used to discover cameras. It might be possible that if you have some certain devices on your network that list similar http services as IP cameras (so we partially discover them) but somehow they take a long time to return their relevant details I could see it possibly causing delays. In general the devices should not work this way and so we have never seen similar behavior here.

It would be very useful if you might be able to download a copy of Wireshark (http://www.wireshark.org/) and take a capture of your network traffic of opening the application and trying to enumerate devices when IP cameras are enabled. This would allow us to confirm if my suspicions are correct. You can filter the capture before saving it using by putting "DNS" in the filter field to ensure that any other traffic on your corporate network is not inadvertently saved. Without this there is not much we can do I suspect because we have not reproduced this here.

Eric

[pj325is]

I captured my network connection with IP cameras enabled and disabled.

For each capture, I just started max and opened my gige camera as quickly as I could and then closed it after letting it sit for a few seconds.

[BlueCheese]

Ah, there is the problem... it looks like you have ~150 HP LaserJet and other network printers that are on the same network as your system running IMAQdx. Generally most networks are subnetted and multicast DNS traffic is segmented enough that you would not expect to be able to see so many printers!

The network printers advertise an "http" service which is the same type of service that most IP cameras advertise. Thus, when we are searching for devices, we get responses from the printers as well. It appears that the multicast DNS stack that we are using (Apple's) must rate limit and/or serialize all the follow-up requests (likely to not flood the network) and so finishing up discovering all the devices is taking more time than expected. However, the IMAQdx driver appears to be working as expected and ensuring it doesn't deliver to the user a list of devices that is incomplete.

For now I would suggest that it may be something to bring up with your network administrator that perhaps all those printers should not be all on the same multicast domain. Presumably you would also encounter similar delays doing things like adding a network printer that makes use of the same discovery mechanism. There is a chance we might be able to optimize some parts of that discovery mechanism (filtering out some non-camera devices prior to getting follow-up information from them) but for technical/compatibility reasons it is tricky.

Eric

[pj325is]

That makes sense.

It was hard enough to get IT to let me turn off McAfee for 2 minutes, so there's no chance they'd change the network to accommodate the handful of developers that work here.  

Thanks for all the help, though.

[pj325is]

Turns out I was incorrect about not needing to enable IP cameras.

Is there a way to enable IP cameras, but restrict the discovery process to a certain ethernet interface?  We would like to have our vision systems remain on the corporate network, while using a dedicated gige network for vision stuff.

[BlueCheese]

---

@pj325is wrote:

Turns out I was incorrect about not needing to enable IP cameras.

Is there a way to enable IP cameras, but restrict the discovery process to a certain ethernet interface?  We would like to have our vision systems remain on the corporate network, while using a dedicated gige network for vision stuff.

---

I don't believe it is possible to do this. We use a system-wide mDNS resolver service that is used for multiple other purposes besides IMAQdx. It might be possible to restrict that service to a specific interface (though I'd have to consult Apple's documentation) but it would block any other applications from using mDNS on other interfaces as well. For the queries that IMAQdx does to the resolver I do not believe there is a way to restrict the interface used.

Eric