Slow IMAQdx v3.7 gige camera enumeration/connection

[pj325is]

I recently upgraded from IMAQdx 3.2 to 3.7 because of an issue I was having with a camera (JAI CM-040GE with new firmware didn't work with IMAQdx 3.2).  The upgrade solved the issue but now camera enumeration and connection in MAX and my VB.Net code take much longer than they did with IMAQdx 3.2.

I used a stopwatch to compare enumeration and connection times on two computers, one with IMAQdx 3.2 (MAX 4.6.2) and one with 3.7 (MAX 4.7), all other software is the same.  In MAX, I timed from expanding the "Devices and Interfaces" tree until "NI-IMAQdx devices" showed up, which consistently took 20 seconds with v3.7 and 2 seconds with v3.2.  Connecting to the camera, timed from clicking on the camera until its information is viewable in the lower info pane, takes 10 seconds with v3.7 and 2 seconds with v3.2.  I timed the  "CWIMAQdx.EnumerateCameras" and "CWIMAQdx.OpenCamera" functions in my application and got similar results.

The rest of my NI software is  DAQmx 9.1, VDM 8.6.4 and VAS 8.6.0.  I tested IMAQdx 3.7 on a second computer with the same results.  I am using the high performance gige driver on all computers.  I tried three cameras: JAI CM-040GE, Basler sca640-70gm and Prosilica GC655M, all with the same results.  Deleting the camera icd and xml files in the IMAQdx data folder did not help.  My employer requires McAfee to run on all systems, but it doesn't affect v3.2 and I don't see anything in the McAfee logs that would indicate interference.

Is there some incompatibility between the software versions I am using? Is it by design? Or is something else wrong?  I can get around the enumeration issue by assuming that "cam0" is present and only enumerate cameras if it isn't, but 10 seconds to connect is a very long time, especially since my application is restarted frequently in development and testing, and in the field to a lesser extent.

[seVEMes]

What operating systems are you using?

[pj325is]

windows xp sp3

[seVEMes]

I tested this and it took from 45 seconds to 1 minute for the two tests with IMAQdx 3.7 on XP. I have never seen much better than 30 seconds on any version of IMAQdx that I have had on my computers so it looks like yours is pretty fast. Also, your older version seems exceptionally fast to me.

There have not been any reported slowdown of enumeration with the upgrade that I have seen. I will try to see if this is expected behavior or if there is something that may speed this back up.

[pj325is]

Wow that is interesting.  What could it be doing that would take upwards of 1 minute?  That is an eternity.  Is the time you mentioned just for enumeration or does it include the time to actually connect to a camera?

I only have one camera ever connected at a time (but it may be "cam0" or "cam1" or etc, which is why I wanted to enumerate the connected cameras), were you testing with just one camera attached or several?

My systems use a dedicated NIC with a direct connection to the camera.  The computers are core2duos with 2gb of ram.

We had been using IMAQdx 3.2 for several months and it was consistently discovering cameras within 2 seconds and connecting to them equally fast.

[pj325is]

Also, just to be clear, I am not talking about the time it takes for the camera to acquire an LLA address. I don't open MAX until after this step:

"then a GigE nework interface controller (NIC) is first connected to a camera or a switch, it may take up to 60 seconds or more for the LLA to be resolved. During this time, the Windows Task bar will show an icon with the message “Acquiring Network Address”.  Once the message changes to “Limited or no Connectivity”, the camera should be recognized in MAX (Refer to Figure 2).

I am talking about the time it takes in MAX and vb.net code to enumerate connected cameras and then connect to them.

[BlueCheese]

Hi pj325is,

Your experience does seem odd and unexpected. IMAQdx does currently "hold back" enumerate and "open" calls from completing until it has some idea that discovery of network devices is complete (this only happens once when the DLL is first loaded and discovery is first started). This is to ensure that applications that open and immediately try to open a camera will succeed, and that the return values from enumeration are consistent and don't start off with nothing listed for the first couple of seconds. Now, in the normal use-case, this should not add much time at all to most applications as network discovery is a process that takes only a couple of seconds.

Between IMAQdx 3.2 and 3.7, the main change affecting enumeration/discovery time I can think of that might affect this was adding support for IP cameras. These are discovered via multicast DNS and I believe it takes roughly 3 seconds for the discovery mechanism to complete. However, this runs in parallel with GigE Vision discovery and thus should not usually add any time over older versions of the driver.

One possible cause for the slowness is a known issue in IMAQdx (that would be present in 3.2 as well) that GigE Vision discovery is serialized over multiple host IP addresses. That is to say that if your system has 5 IP addresses it may take 5 times longer for discovery to complete compared to a system with 1 address (with each address usually adding ~1 second). For comparison, my system here has 4 IP addresses (one on the corporate network, one with a link-local address, and two VMWare virtuall interfaces) and eyeballing it it takes roughly 4 seconds from when I open MAX and expand Devices and Interfaces to when my IMAQdx cameras appear. Is it possible that your setup between IMAQdx 3.2 and 3.7 differed in how many IP addresses you have?

Eric

[pj325is]

The systems that now have v3.7, had v3.2 up until a few days ago.  They are no different than they were before, and they are no different than the systems that are still running v3.2.  I have actually uninstalled v3.7 and reinstalled v3.2 on the two test systems and the enumeration and open times return to their previous values (a few seconds for each).

The machines I am using are just regular XP machines, so I believe they only have IP addresses for the corporate network and LLA.  

Could the different behavior of v3.7 cause McAfee to react differently than it did with v3.2?  Even though I see nothing in the logs, maybe it is blocking or delaying the v3.7 traffic in some way that causes it to take much longer than usual.  If you think this is a possible cause, I could get in contact with the IT dept and see if they will let me disable McAfee to test this theory.

[BlueCheese]

I have not seen similar behavior to what you have described. I have McAafee here as well but it is certainly possible that the options enabled are different. It seems worthwhile to try investigating that path since any delay in sending the discovery traffic could cause that process to take longer.

You could also try adding/setting the registry key "EnableIPCameras" under HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\niimaqdxk\Parameters to "0" to disable support for discovering IP cameras and see if that makes a difference.

Eric

[pj325is]

Disabling McAfee had no effect on the enumeration and connection times, neither did the "EnableIPCameras" registry key.

However, I tried disabling the primary network connection (to the corporate network), so the only active connection was from the computer to the camera, and the enumeration and connection times dropped to below 4 seconds each.

The network I am on is pretty large (4152 connected machines), and it takes windows 15+ seconds just to list them.  Could just being on a large network cause it to slow down, even though IP cameras are disabled?

I attached a screenshot of the registry setting to make sure I added it correctly.