Slow response to ImaqDxSetAttribute (intermittent)

[jhc2]

I'm using ImaqDxSetAttribute to provide a software trigger to a pair of Basler GigE cameras. I need to coordinate the frame acquisition with transitions in a filter wheel. When the filter wheel transition has completed, I use SetAttribute to generate a software trigger to each camera (one at a time). Following each trigger, I use ImaqDxGetImage to capture the frame from each cam.

The problem is that I get intermittent pauses on the call to SetAttribute. It occasionally takes up to 5 seconds to return control to my code (but it still generates the trigger). Typical trigger times without this pause are ~90 milliseconds.

My development environment is C++ CLR in VS 2005.

Comments / suggestions appreciated.

Thanks in advance -

[BlueCheese]

Hi Jhc2,

Firstly, are you using IMAQdx's C interface or the native .NET layer in your CLR code? Do you possibly have some other code accessing the camera session at the same time? Some operations must have exclusive control over the camera session and can block others (although 5 seconds does sound odd). If you could provide a small sample app that can reproduce this it might make it easier to see what could be going on.

Eric 

[jhc2]

Hi Eric:

I'm using .Net's Interop facility to call IMAQdx from within my managed code. This is a technique I've used successfully before with the older IMAQ (no -dx) SDK, so I think it ought to work. I am not using NI's .Net controls.
 

I'm attaching a zip of a stripped-down VS 2005 WinForms project that reproduces the problem. This app only calls IMAQdx functions. I think it ought to be clear what I'm doing - with luck, any mistakes will be clear too. When you click 'Start', the program loops to open/configure, acquire, unconfig/close. That sequence repeats until you click the button again.

The sequence ought to take a little over two seconds. Timing is traced to the debug output window. See Test_log.txt for a copy of the trace output that shows both a bad run and a good one.

Further details: the system has a GigE Vision NIC installed. A screenshot of the driver details is in the zip. The NIC is connected to a gigabit switch from Advantech (EKI-2725). The two Basler cams (pia2400's) are attached to the switch. The cams are large format: 5.5 mpixels and set up for Mono16 format. Jumbo frames is enabled for all apps.

As an aside, I'm not married to the trigggering approach though I would like to keep it. I've tried just running continuous, non-triggered acquisition (grab and non-grab) on the cams without success. I ran into the 'streaky image' problem that others have seen. Your suggestion to those folks to throttle bandwidth to limit packet loss sounded good, so I reduced the DesiredMaxBandwidth property on both cams - but had no luck with that approach. 

Thanks for the reply -

[jhc2]

Hello again

I'm still pursuing this timing problem. To eliminate .Net's Interop as the cause, I rewrote my test program as an unmanaged console app. That project is attached. It was generated with VS 2005 (and uses MFC) but is pretty much plain C code. It includes NiImaqDx.h and links to NiImaqDx.lib, the files from the NI installation.The code in TriggerB.cpp ought to build in most VS versions

The console version shows the same symptom: an intermittent 5-second delay when IMAQdxSetAttribute is called to generate a software trigger. See the file named Test_log.txt in the zip. I have checked the cabling between cams, switch and NIC but saw no problems there.

At the moment, I'm pretty confident the problem's not in the app code or the cabling. That leaves: IMAQ, the NIC, the switch, the NIC's driver (& config) and Windows' TCP stack (& config).

Any suggestions on how to get clues from the IMAQ session to help narrow it down will be appreciated.

Thanks in advance -

[BlueCheese · Accepted solution]

Hi Jhc2,

I apologize, but I have not had time yet to gather together two Basler cameras with the requisite software trigger to try to reproduce this with your sample code, although I did look over the code and did not spot anything that looked like it should be a problem.

I am suspicious of one item though. There is some errata with the latest Basler firmware that we are working with them to get resolved that might cause command acknowledgements (such as for the software trigger) to get lost. If IMAQdx has to retry the command it would account for that 5 second delay. I think this issue does not appear when using smaller packet sizes. If you were to try dropping down to 1500 byte payloads, does this change the behavior?

Thanks,
Eric 

[jhc2]

Hey Eric

First, there's no need to apologize. You guys provide great support at this site & I appreciate it.

Second, your suggestion about packet size looks very good. I used your 1500 byte setting on my cams and my test app made over 20 passes without a problem. Previously, I've never been able to get more than 3 passes without seeing the problem.

Finally, how can I get a copy of the Basler errata sheet? Is it available on their web site? I'd like to pass it along to the team member who buys the cameras and to our distributor.I've used IMAQdx and software triggering with Basler cams before, so I guess this is specific to my current model (pia2400).

Many thanks -