IMAQdx Timeout Error 0xBFF6901B

[Megabite]

We are developing a GenICam compliant camera. In Max I can connect and configure the camera without problem. But, IMAQdx always times out on the first frame after connecting to the camera. The second and successive frames work fine with no timeout.

Firewall off. Jumbo frames on. Works fine with another GenICam control and capture app.

Obviously before posting this problem I searched the forums.  We do not send test packets.  I tried the following suggestions - http://forums.ni.com/t5/Machine-Vision/IMAQdx-Timeout-Error-0xBFF6901B/td-p/583335 and http://digital.ni.com/public.nsf/allkb/8D9A975B04F66B728625768900805A21 and http://forums.ni.com/t5/Machine-Vision/GigE-Vision-Basler-SCA1600-14gm-Error-Timeout/td-p/1769224 and http://zone.ni.com/devzone/cda/tut/p/id/5846

Disabling Test Packets did not fix my problem. Is IMAQdx somehow ignoring the setting?

Any other ideas?

[BlueCheese]

Perhaps you could take a capture with wireshark of a "snap" in MAX and post it?

Eric

[Megabite]

I have that. There is a lot of data.  What would you like to see?

The Wireshark capture looks OK.  The only difference I see is the amount of time between writing to register 0xd314 (start acquisition) and writing to register 0xd318 (stop acquisition).  For the first frame the time between register writes is 5000 ms which is the current timeout value. For the second frame the time between register writes is ~125 ms.

[BlueCheese]

So it is not that the first frame is lost, it is the first frame of the first acquisition? Subsequent acquisitions work fine?

What are the block_ids being sent by the camera? Perhaps your first image is starting with an invalid block_id of 0 (and is being ignored by IMAQdx) and on subsequent acquisitions it is starting at a different id? [Note that this likely is incorrect behavior per the spec since IMAQdx closes the stream channel each acquisition and so the block_ids should start over each time].

Eric

[Megabite]

The first frame is sent but IMAQdx ignores it and times out.  The second frame is sent and IMAQdx receives it and every frame after that.

I do not know the block_id (isn't that a 1394 camera thing?) For some reason I cannot determine, Wireshark does not collect or display the data frames, only the standard requests. I assume the data is sent since it works on the same computer with a different application. And I can see the data packets when using the other program.

I do not know the block_id because I am using a thrid party GigE chip.  It handles all of the ethernet stuff. All I get is a tiny trickle out the back end. If you want me to verify the block_id then I need to know how capture the data packets when IMAQdx is connected to the camera.

[BlueCheese]

My guess is you are using NI's High Performance GigE Vision driver. You should be able to go to device manager and switch the driver association of that NIC to the standard Intel driver and then you should see all the traffic.

[Megabite]

Changed to the standard driver.  Now I get a timeout on every frame.

[BlueCheese]

Can you attach a wireshark trace?

[Megabite]

My original problem was 0xBFF69031, "The system did not receive a test packet from the camera." When I unchecked Test PacketEnabled, then I got the error "0xBFF6901B, IMAQdx Timeout Error."

I have attached a trace showing that a test packet is sent in response to the request from IMAQdx. Take a look at the sequence starting around #2181.

Why does IMAQdx display an error?

[BlueCheese]

That error means the image data is not going through. We use a test packet first so that we can differentiate between a network connectivity problem vs simply the camera not sending any image data. If you disable the test packet then you are just going to see that no image data is received.

The error message states that one likely cause is that the firewall is enabled. If you have the Windows firewall on it should be disabled if you are not using the High Performance driver (alternatively you could enable the Firewall traversal feature, but this requires your camera to support this feature).

Eric