dataloss with VBAI - 64bit?

[declercq_tom@waak.be]

Hello,

I run VBAI 2012 (runtime license) for an application in wich I run 4 VBAI-programs on 1 computer. When trying to implement this system we've encountered some dataloss-problems. See: http://forums.ni.com/t5/Machine-Vision/black-stripes-bandwith-problem-Vision-Builder-AI/m-p/2493720#...

With the help of several contributors we were able to solve this.

The last couple of months we started having problems again. Occasionaly we see black horizontal lines. When we check our networksettings, the icd-files of our cameras... everything seems ok. We looked at our antivirus with ICT, but that didnt seem to cause the problem.

We tought general network problems could be the cause, but even when running local (1 computer, 1 gigabit-switch and 4 cameras, not connected to our network) we had some dataloss.

Any ideas what could be the cause? All input is welcome.

Ps. We run this application on a 64-bit computer with windows7 64-bit. Seeing as there isnt a specific 64-bit version of VBAI we are wondering if VBAI can use more then 4GB memory.

With kind regards,
Tom

[declercq_tom@waak.be]

Anyone?

My concrete questions are:

• Can Vision builder 2012 use more then 4GB?
• Does anyone have any other suggestions about why there are (at random intervals) black stripes (eg lost datapackets)?

Any help would be greatly appreciated.

With kind regards,

Tom

[BlueCheese]

VBAI currently is a 32-bit app, meaning limited to 4GB per instance (multiple running instances can each get their own memory though).

As for your data loss, it is pure packet loss and is unrelated to memory or anything like that. This points to your network topology as the issue. Running multiple cameras through a switch is hard, because it requires the switch to buffer packets and they tend to have very small buffers. Throttling the cameras so that the interpacket spacing is larger is the common way to help alleviate it, but if all your cameras are triggered at the same time it might still be hard for the switch to accommodate all of them sending simultaneously.

Some suggestions:
-Remove the switch and get a 4-port card such as the NI PCIe 8233
-Try a higher end switch with more packet buffering
-Try increasing your interpacket delay on the camera further
-See if the camera allows spacing out the image frame transmissions completely so they don't overlap (transmission delay)

[Brad]

Good points blue cheese. Also worth noting that you should make these changes in VBAI because the steps in VBAI use their own settings so any changes you make in max don't affect the settings used by your inspection in VBAI.

[declercq_tom@waak.be]

Thanks for the input!

Later this week we will throttle the camera as you recommend. I'll give an update asap.

Also later this week I'll discuss the switch and its properties with our ICT-department.

Concerning the 4-port card: I'll keep this as a last resoure option. If all else fails this is certainly an option, but then I'll need to buy a new computer too, so I would rather find another sollution.

With kind regards,
Tom

[declercq_tom@waak.be]

Hi all,

Sorry for the delay. Due to continuous production, we couldn't adjust any settings. Next week however we get two days to 'play' with our system. We will then try to throttle our camera's and keep you updated.

With kind regards,

Tom

[declercq_tom@waak.be]

Update:

The last couple of months we have tried several things as recommended by you:

* We've removed the switch by another one wit more packet buffering - same results.

* We've increased the delay of each camera so that the second one will only take a picture 500milliseconds after the first one, the third 500ms after the second... - same results.

For the moment we are discussing wether to buy a new computer with a 4-port card. The decision about this should be taken by the unit manager by next tuesday.

We do have one more question however: Can our graphic card be the source of the problem? We've always said that this shoud be a network problem, but are we sure about this?

With kind regards,

Tom

[Brad]

When I got it working, I only started the Server by pushing the button at the bottom of that dialog. I did not configure a client in the top portion of the window. The C code allows you to specify the IP Address and port of the smart camera, so you should not specify any IP address on the VBAI side running on the smart camera...this could create another device which steals packets from the TCP Server that you want to use, or you could use the wrong device in the TCP step if you have the server configured and a client configured.

When you only have the VBAI TCP Server started, make sure your TCP steps point to this one TCP device and then once you have the inspection running on the smart camera, you can run your C app on the host and it worked fine for me when I did this.

Hope this helps,

Brad

[declercq_tom@waak.be]

Hi Brad,

I'm sorry, but you lost me for a moment. Actually we dont use a smartcam, but 4 'dumb' cams.

We gave each camera an IP-adress and in VBAI we select the cam we need for that specific program.

With kind regards,

Tom

[Brad]

Sorry about that...I was responding to a different post. To answer your question about the graphics card, I would bet that if the black lines you see are just in the image display control and not anywhere else on the UI, it's a camera/network problem. I have seen poor graphics adapters dramatically decrease perfromance if there are images being displayed and as soon as I minimize the app it works much faster. One way you can test your theory on the display adapter is to log the image to disk and see if the images saved to disk have the black lines...if so, there's some camera/network issue. If not, it's a display/cosmetic issue.

Hope this helps,

Brad