GigE Basler-sca-1400-30gm Imaq-dx Software trigger ResendPackets problem

[toineroetman]

I want to use 3 cameras with LED switch at exposure time of the camera.
Because the LED light from each camera influence the picture of the other
it is important for me the switch them after each other.
So take picture first camera1 with LED1 and then take picture camera2 LED2 and
then camera3 LED3.

For some products types it is 1,2,3 for others 2,3,1 for others 3,2,1.

To do this I used software trigger because this gives be flexibility to do the job.

Unfortunately I get ResendPackets from Imaq-dx when using software trigger.

I get this when I use 1 camera and also when i use more then 1 camera.
I get this when I use no wait time and I get them when I use wait time between taking images.

With the same hardware and almost the same software (only no software trigger) I get
NO ResendPackets at all.

To me it looks like a software problem somewhere.

I use:
- Labview 8.6.0
- Max version 4.5.0f0
- NI-IMAQdx 3.2
- NI-IMAQ 4.1

For source and testing programs see ZIP file:
   test-basler.zip
  
For the test results see Word-doc's:
   imaq-dx-software-trigger-delay-200msec-ResendPackets.doc
   imaq-dx-NO-software-trigger-delay-200msec-NO-ResendPackets.doc

Hopefully someone can help me solve this problem.

Thanks

[Vladimir_Drzik]

Why do you think receiving resend packets is a problem? GigE is an inherently unreliable interface, so there is always a chance that a packet is lost. The IMAQdx driver solves the situation by requesting a packet resend if a packet does not arrive in the specified timeout period. So you might set the timeout period lower to reduce the jitter of the image arrival times. If you need to further improve the jitter, I would suggest improving the hardware - using NI's or Intel's GigE adapters + having a separate adapter for each camera. Anyway, in my opinion you can never get a perfect communication determinism on the GigE vision interface. Secondly, I assume you are running your application on a non-realtime operating system. This fact alone prohibits you from getting deterministic image arrival times.

Regarding your observation that the resend packets do not occur when using hardware trigger, I am not sure. Maybe the issuing of the software trigger causes some additional communication on the GigE bus, which sometimes causes a lost (and consequently resent) packet.

[toineroetman]

Thanks for your reaction Vladimir

I use the Intel pro 1000 adaptor and use only the NI driver. I use a seperate adaptor for each camera.

I use Windows XP but even at the fastest rate the cpu load is only 3%.

Without the software trigger i took 60 000 000 for 2 cameras parrallel without any delay and WITHOUT any resend.

With the software trigger about every 5 000 there will be a resend. Even when i slow down the acquisition to 1 picture in

1 second.

As you suggested I lowered the Resend time out delay so the jitter is less now.

In my opinion it does not look like a hardware problem.

[toineroetman · Accepted solution]

I found out that the problem lies in the hardware setting off the i7 CPU 610.

The CPU has very little to do when using a Intel pro 1000 adaptor (PCI Express 4x) and use only the NI driver.
I use XP Sp3

The CPU somehow is using the power saving and that effects the bus. I do not know exactly why!

The first solution I tried was using a labview program that uses 100% CPU. That already give much less problem.

Then I tried switching off the Bios Hardware CPU configuration “C-States” and Disabled that one.

See Word document.

Then the problem was solved.

Toine