IMAQdx: Extremely slow GigE camera

[martijnj]

Hi all,

I have two GigE cameras, an AVT 1920-GX and a Photonfocus MV1-D1312I, simultaneously connected to different ports of a dual port Intel Pro/1000 PT adapter. I want to be able to control both cameras and download images from a single LabView application.

Let me start by saying both cameras work in IMAQdx: I followed the devzone advice (http://zone.ni.com/devzone/cda/tut/p/id/5750 and http://zone.ni.com/devzone/cda/tut/p/id/5846), got both cameras working and can poll/set attributes as well as download images. However, the Photonfocus camera seems extremely slow at initialisation and configuration, which I believe to be a software problem

In measurement explorer, opening the relevant camera pane takes ~1s for the AVT but 11s for the Photonfocus. Pressing "snap" takes <1s for the AVT and 3s for the Photonfocus.

This makes the Photonfocus just sound like an extremely slow camera, but using the distributed software GEVPlayer the camera responds instantaneously. GEVPlayer can control both cameras, and there is no discernable difference in performance between them (initialisation/configuration/acquisition time) when using that program.

Attached is a testing VI, which connects to the camera, configures it for a single frame, polls the trigger modes and sets it, then acquires a single frame, timing each section. Results (unaveraged but illustrative) are:

	AVT	Photonfocus
Init:	261	4716
Config:	20	2126
Attrib:	1	36
Active:	75	71

Given that both talk the same GigE standard and there is clearly no hardware bottleneck because both can work fast, why is this particular single camera so slow when using IMAQdx?

For our applications these large timing delays are unacceptable and have implications for our further work so I am very keen on finding a solution

Using LabView 2010 Professional SP1 and Measurement Explorer v4.7.7f0 with NI-IMAQdx 3.8

Cheers,

Martijn

[David-A]

Hello martijn,

There are a couple of reasons that your camera could be initializing slowly, but before we delve too deeply into any of them I would first recommend upgrading your version of IMAQdx.  You can find a list of our most recent Vision Acquisition Software here.  According to this chart you should be able to use our most recent version of IMAQdx.  Please post the version number you upgrade to and any resulting change. 

David A

[martijnj]

Hi David,

Thanks for your reply; I've upgraded to NI Vision Acquisition - September 2011, now showing IMAQdx version 3.9.1 in MAX System Information. However, there doesn't seem to be any improvement in interacting with that one camera, it's still taking over 10s to connect in MAX and my test VI reports similar numbers.

Also, forgot to mention before, we're using Windows 7 SP1 and there's no change in behaviour when the other camera is disconnected, and the same behaviour is observed when connected to a different computer with the same LabView install.

Cheers,

Martijn

[David-A]

Hello martijn,

Would you be able to try acquiring an image after uninstalling the vendors software? Driver conflicts may be causing some initialization delay.

Also, before you uninstall the vendors software, you may want to test to see if the software initializes the camera as soon as it starts up. You can test this by trying to snap an image using MAX after the software has been loaded. What this would tell us is that the initialization delay is unavoidable and is simply being masked by the vendors software by initializing it at start up. If this is the case you would be best served by initializing the camera when your program starts, and then snapping an image on demand and without delay at a later point in your program.

Regardless, I would recommend testing the initialization delay without the vendors software installed.

David A

[martijnj]

Actually, we only installed the vendor software in the first place to diagnose whether there was a hardware problem making IMAQdx so slow! Regardless I've uninstalled it again (it uses the Pleora eBus SDK) and saw no difference in execution speed.

I didn't quite understand your comment about snapping an image in MAX once the software loads - as in, wait for NI-IMAQdx to populate, click the camera and snap as soon as it shows? Because that's what I've been doing and it takes 15s to do both. I also tried removing the "Configure Acquisition" VI from my test program but then "Start Acquisition/Get Data" part took 2.2s instead.

Since I don't know how IMAQdx works internally, I am still confused as to why one make of our GigE cameras is fast and the other is slow given that I understand both use the same GigE protocol (especially since Pleora's GEVPlayer seems to control both cameras perfectly even though AVT have their own SDK). It doesn't make sense to me to see such device-specific behaviour when I know the generic protocol works great in other software. Is it possible to determine which driver IMAQdx is actually loading and using?

I also note that putting the Configure-Query-Acquire part of my test VI in a loop shows subsequent calls to Configure take ~60ms instead of 2s, so it really is just the first call. This 7s initialisation time is actually the longest delay in a multi-device synchronised control system, so it would be highly desirable to find a solution. Especially since we don't understand why one camera should behave differently from the other.

[David-A]

I suspect that the configuration for that specific camera is inherently slower.  Subsequent images take a short time to acquire because the camera is already configured.  My suggestion with snapping an image in MAX was to determine if the vendors software hides the configuration time by configuring the camera when the application launches.  If it configures the camera when it launches then you would be unable to access the camera in MAX while the program is open since only one application can have access to a resource at a time.  Thus, launch the vendors software (launching it should take at least as long as IMAQdx does to configure the camera), then launch MAX, then try to snap an image from MAX.

David A