black stripes - bandwith problem - Vision Builder AI

[declercq_tom@waak.be]

Tests performed yesterday:

* 1cam - 1 computer - no switch - no interfacing - without writing the images: problem didnt occur.

* 1cam - 1 computer - 1 switch - no interfacing - without writing the images: problem didnt occur.

* 1cam - 1 computer - no switch - no interfacing - writing the images on a local drive: problem didnt occur.

Today we wil repeat the test with 1 cam - 1 computer - over the switch - without writing images - with all our bandwithparameters set to the maximum to see if we can reproduce the problem like that.

I'll keep you all informed!

With kind regards,

Tom

[declercq_tom@waak.be]

Getting closer! Tests performed today:

* 1 cam - 1 switch - 1 computer - without writing the images - with max peak bandwith op 1000 en streambytespersecond op 115000000: problem didnt occur

* 2 cams - 1 switch - 1 computer - without writing the images - with max peak bandwith op 1000 en streambytespersecond op 115000000 for each cam: problem occurred once In 1 hour.

* 4 cams - 1 switch - 1 computer - without writing the images - with max peak bandwith op 1000 en streambytespersecond op 115000000 for each cam: problem occurred almost immediate.

*4 cams - 1 switch - 1 computer - without writing the images - with max peak bandwith op 200 en streambytespersecond op 25000000 for each cam: problem didn't occur. But we only tested this for half an hour. we'll test this some longer and keep you updated.

So probably a bandwithproblem (as we originally suspected).

We also noticed something strange. A while ago we've set the StreamBytesPerSecond to 25000000 for each cam. When we wanted to change this parameter to 115000000 however we've noticed that it was already set to that. (Is this a default value that resets itself?)

After noticing this we've switched everything of and started it up again. This time our value remained set to 25000000. We've switched everything of again and will check this value again tomorrow morning.

with kind regards,

Tom

More news tomorrow.

[falkpl]

I have come very late to this discussion, sorry if I missed something.

Have you considered running a 4 port card?  I found that using a switch so save a few bucks on an intel single port card (vs 4 port card) can be a source of frustration where you introduce multiplexing multiple cameras on a shared card could cause some lost packets (possibly)  When I run over a switch I typically dont run multiple cameras in parallel or run at a lower total throughput.  GigE uses UDP and as traffic is increased over the channel you could have some lost packets (UDP is lossy).  I avoid switches when possible.

Just a thought.  Only issue is that this usually needs a pcie4x and it is not free.

[ThiCop]

Thanks for updating the forum in parallel  to the phone talks we had!

I'm looking forward to the new results.

[ZcuBa]

Hi again,

It does sound like a bandwith problem then, but it shouldn't be with the data you have provided.

But then again, just to verify, we could re-calculate and check if your resolution is low enogh, / framerate too high..

- also I never asked you about the image resolution, as I simply assumed that you had checked the calculations, and had verified that bandwidth was available.

from:

http://www.alliedvisiontec.com/fileadmin/content/MULTIMEDIA/Images/Support/gige_controls_v1-20.pdf

"To calculate the required minimum StreamByetsPerSecond setting for a camera in any image mode, 

use the following formula:
Height x Width x FrameRate x Bytes per Pixel (see ImageFormat)

NOTE: If you are seeing occasional “black images”, or occasional frames/packets reported as
StatFramesDropped/StatPacketsDropped you will likely need to decrease this parameter.

"

Please read out the values:

StatFramesDropped and/or StatPacketsDropped

to see if the system is aware that errors have occurred during image transfer.

please check that:

StreamBytesPerSecond >= Height * Width * FrameRate * Bytes per Pixel

and that the network can deliver the data at this datarate.

lets do a napkin calculation

first lets approximate the throughput on your network setup:

http://wiki.networksecuritytoolkit.org/nstwiki/index.php/LAN_Ethernet_Maximum_Rates,_Generation,_Cap...

UDP data maximum thorughput (no collisions, no other traffic on network)

119,635,891 Bytes/sec

maximum settings for streaming:

115,000,000 Bytes/sec

chosen framerate (from previous post):

1 / 500ms ~ 2 fps

maximum available data per image (one camera):

115,000,000 [Bytes/sec] * 0,5 [sec] => 57500000 Bytes

this means that the maximum image size when using 1 camera at 2 Hz is:

Height * Width * Bytes per Pixel <= 57,500,000 Bytes

which is plenty for most images.

however at 4 cameras, you get 4 * 2fps => 8fps

and then

maximum available data per image (one camera):

115,000,000 [Bytes/sec] * 0,125 [sec] => 14,375,000 Bytes

remember this is probably 3 bytes pr pixel..

meaning that height*width <= 4791666

or approximately a resolution just below 600x800 ...  😉

my guess is that by setting streambytespersecond op 25000000
you will lose frames, as the camera doesn't trigger while it is transferring images.
but the frames recieved are complete.

[declercq_tom@waak.be]

Hi Zcuba,

Thanks for the usefull info.

Our images have a resolution of 1624 x 1234 (8-bit) and we only take 1 image every 5" (with each of the 4 cameras). So our MaxPeakBandwidth shouldnt be the problem.

However, as mentioned in our previous post, we did notice that for some reason MaxPeakBandwith was reset to its initial setting of 115000000.

We have lowered this value and are seeing alot of improvement for the moment. We'll let you know how the tests continue.

We aren't sure about the reason of the resetting of this value. Something to do with the icd-file?

When we find out more about this we'll post it as well.

Kind regards,

Tom

[declercq_tom@waak.be]

Hi Falkpl,

Our framerate is only 0.2frames per second (with 4 cams at approxemately the same time).

So this shouldnt be a problem.

However, if the problem isnt completely solved in the next couple of days we will certainly consider working without switch.

With kind regards,

Tom

[ZcuBa · Accepted solution]

You will typically find a camera configuration file (xml) at a path similar to this one:

C:\Users\Public\Documents\National Instruments\NI-IMAQdx\Data\XML\cameraname.xml

That particular file is used to store camera settings in, and is at first communication with the camera populated by the values reported by the camera.

After initial contact, changes saved using MAX will overwrite this file.

most of the implementations I have seen transmits the settings from this file to the camera on connection.

so if the setting in this file is the 115000000.. or if you changed computer to one where the new setting was never saved, you'll se the problem.

you should either save settings to the file from your application, or transmit new settings to the camera after establishing connection, before starting the capture, to make sure that this doesn't happen again.

[declercq_tom@waak.be]

Hello everybody,

First of all I would like to thank everybody that contributed to this thread. Your input was valuable for me and I believe it may help others in the future.

The problem seems to be solved. Since adjusting the streamBytesPerSecond parameter on the pc where we run our application the problem ceased to occur. We still see a single black horizontal line every now and then (about once every three- to fourthousand images). But we can live with that.

Zcuba,

We found the file you refer to. In our case however we only find 1 file with the general name of all our (Allied Vision Technologies) cameras.

What we do find however are icd-files for each camera in C:\Users\Public\Documents\National Instruments\NI-IMAQdx\Data\

We suppose that the problem that you described happened with this file.

With kind regards,

Tom