VBAI Performance

[OZI]

Hi

we are using VBAI 2012 full version and we wrote an application on our computer using a Basler GigE cam. To see how fast our application is running we use from time to time the benchmark function. But the results are confusing. Sometimes we get only the performance to check 1 piece a second. After closing and restarting VBAI the same application gives us a speed of up to 4-5 pieces a second.

Is there an effect that the application gets slower by a longer use of VBAI? How can we avoid that our application gets to slow.

By comparing the results in details we see that some functions need 10 times the time when using VBAI for a long time in comparison to after a restart of VBAI.

How can this be?

greetings

Oliver

[Brad]

What steps are taking so long? I would not expect the behavior you describe, but there may be some steps, for example data or image logging, that produce results and each time, the size of the data/number of files grows and if you are doing some operation with those files, it may take longer and longer each time maybe. Is it possible to send a simplified exmaple that reproduces this problem and doesn't require any hardware?

Thanks,

Brad

[OZI]

Hello Brad

I will do some tests today and publish the results after. My problem is that I do not understand why steps take different time to run. For example steps like vision assistant or calculator. I will try to get results today and publish them

greetings

Oliver

[Brad]

Another factor that I have seen that seems to "mysteriously" make some steps take longer is when a task is running in the background. The performance meter simply benchmarks how long a particular step takes to execute and so if a background task is running, it may make a step seems like it takes longer than it should, or the delay may even jump around to various steps, when really the processor is spending part of the time doing something else. In particular, some PCs have really poor video adapters and displaying the image can take longer than you'd expect. Since this update is done by the OS, it can happen asynchronously anytime and it may consistently happen when some random step runs (i.e. the Calculator) or it may jump around and make it look like different steps take longer depending on the iteration, when really it's the OS updating the image that is taking most of the time. Try unchecking the updating image box above the script steps in VBAI for all the states and see if you have any background image or data logging that may also happen in the background. Hope this helps, Brad

[OZI]

Hello Brad,

thanks for this idea we will try to uncheck the updating image box.

Meanwhile we changed the application that it will run on the VBAI Server and a CVI program controls the application. Today we made some measurements, the results are not so good as expected, we can only check three parts a second. It is enough for our application but there will be no more reserve. I attached the results to this message. You can see the different results of five measurement. The most different value is the time the inspect needs.

Is there any possibility to give the server a higher priority that it will run faster?

best regards

Oliver

[Brad]

Are you working with large image sizes? Do you have a small amount of available memory available during your inspection (less than 1GB)? The large variations in execution time for many of the steps makes me think your computer is running out of memory and doing any image manipulation that requires copying the image could take a long time if there's not much memory available. How much memory do you have available while the inspection is running? How much total memory do you have? If you have less than 1GB free, I would recommend upgrading to have more memory. Also try turning off the image display flag as mentioned earlier and let us know how that goes.

Hope this helps,

Brad