CVS Benchmarking

[Median9]

While benchmarking on a CVS 1454 using Basler camera, i get 100 ms, which means 10 Frames Per second. But when i run the CVS in a real application, and display the parts / second reading, it always stay below 6 parts / second.

I want to know the reason. If i am benchmarking at 100ms, then why is it not giving me 10 parts per second in real application?

Sincerely,

[J.Harv]

Faisal--

     In the help for the benchmarking it mentions that the benchmark is only for the acquisition steps and does not include any input, waits, or image displaying.  The benchmarking tool is only an estimation.  If you run the application and it takes slightly longer I would use this value as your "benchmark"  You could also look to see, are you actually running the program from the CVS? If you try to run in inspection mode from your computer it has to send the values through the network, back to your computer and this could cause that delay.  Verify the time when running the program embedded on the CVS.  That is about all I can think of.  I hope that helps.

Regards,

John H
Applications Engineer
National Instruments
http://www.ni.com/support

[Median9]

Dear John,

Thanks for the response. Yes i have tried the program embedded in the CVS as well. It is strange, because none of the acquisitions go past 5 parts per second (200 ms), even if i had benchmarked them at 67 ms initially. I wonder where do the additional 133 ms go? I have checked all the delays due to triggering and rejection pulses, which add up to a total of about 8 ms. I have tried both VBAI 2.6.1 and 3.0.

How about If i removed all the steps between 'acquire image' and 'decision making', should that speed up the acquisition in the embedded mode? Just to make sure if it is one of the steps inside the script that is acutally taking long. I have not tried that yet. But if doing so really speeds up the application, wouldnt that mean the benchmarking is giving out false calculations?

Sincerely,

[J.Harv]

Faisal--

      That is strange, the benchmark should be accuate when run embedded on the CVS.  How were you reading the times?  If they are from your computer then that's likely the hold up, sending info back to the computer. Like I said though, the benchmarking utility is only an estimation and likely to vary with incresing complexity of code. The more steps and the more signals you have the more processing and waiting there is. If you really would like to find out where this is happening, I think that taking parts of the code out and re-checking the time would be the best way to do it. If it is just gradual offset with each step it might be hard to correct. If you find out that it is one step in particular that is causing this behavior then maybe it's a bug?  So if you want to narrow it down that might help. Let me know if you find something.

Regards,

John H.

[Median9]

Dear John,

I am sorry for responding so late. I have tried everything since your last email but the problem still persists. When benchmarking with the PC connected to the target, i now get 138 ms (i am doing this separately with both Golden Template Matching and some other scripts like Fast fourier filters etc.). 138 ms (7.25 parts per second) is ok for the real application. But when i run the application embedded on the CVS1454, and display the "parts per second" on the monitor connected to the CVS directly, it still shows below 3 parts per second.

When i remove the steps (Golden Template Matching or FFT filters etc.), the speed increases to above 20 parts per second. This definitely means that these steps do take a lot of processor time, but there is a difference of more than double between the benchmarked time and the embedded application time. Which is not less than a surprise for me. I am using VBAI 3.0. I have also tried the new "Inspection Setup" and "Inspection Cleanup" properties but there was no difference.

Another problem is that i am getting a "flicker" in the image overlay. i.e. the Red/Green Pass/Fail button displayed on the monitor flickers (vanishes and displays once again) every time there is a trigger on the CVS and it displays a new image. I have found out that the reason for this flickering is the "Display Image" step that i am using before "Custom Overlay". I tried to swap these two so there is the "Display Image" step after the "Custom Overlay" step in the script. It does remove the flicker but then there is another problem: When the machine stops, i.e. there is no trigger for more than 5 seconds, the Green (Pass) button on the monitor turns Red (Fail) after the camera trigger times out even if the last displayed image was correct (Pass/Green). This also turns 'ON' the rejection bit at the CVS output Port. This 'bug' was there in VBAI 2.6 for which i upgraded to VBAI 3.0 which seemed to be a definite solution but it did not work either. Ultimately i had to re-arrange the "Display Image" (i.e. Display Image => Custom Overlay) so that this atleast permits a smooth running, but trading off with Flickering.

I have 1 year ssp and some people from NI have contacted me for a solution but there is no development so far. I will appreciate if you could help me out on this one.

Sincerely,

[J.Harv]

Faisal--

         Like I said before, the benchmarking feature is only to get a rough idea about how long an aquisition, will take.  Not processing.  If you are doing a lot of processing on the image it really won't matter what the benchmark says.  At that point it is no longer relevant.  With a step like Golden Template, it will definately be different.  As you saw when you removed this part for the actual inspection.  You were saying it takes so much longer on the CVS as compared to the benchmark on your system.  Once again, they are two different environments and there is a lot going on behind the scenes here.  For instance, where does the template image come from?  If it is from your computer the CVS will have to comunicate with your computer; whereas when it is on your computer, the image is already there.  It could be anything.  My previous advice was to take parts out of the code and see where the major delay is.  It appears now that it is with the golden template.  So take it one step further and try to change/configure this section to try avoiding the delay.  If you have any specific questions about something you are trying or seeing just let me know.
       As for the flicker.  When you have "display image" it will display the image and replace any overlay that is there. And then repeat this process. You might first try to take it out and see whether this changes your code and how.  Is the diplay image necessary?   If you take it out, the image and overlay should still be shown at the end of the inspection step, but it is pretty simple to try out.  Just let me know.
    As for why the delay is there when the display image is in front of the other is hard to say.  Just changing those two things around should not have an impact.  When this happens you say there is no trigger...is that a trigger from the CVS to the camera?  You said that people from NI contacted you about a solution, I would suggest continuing to work wtih them and see what they can do.
      If you have support, I would really suggest creating a service request (SR) and either calling in or sending an e-mail to work with an engineer directly.  You seem to have several issues here and it would be much more efficient to go directly to an engineer.  You can create an SR on the web or give us a call.

Regards,

John H

[J.Harv]

Faisal--

    Also, wanted to check, you are running the program embedded on the CVS, where the program is set to run at startup and you have included the template image into the CVS right?  When on the CVS, it is completely independant from your computer at that point, right?  That is the preferred method, so that it doesn't need to comminicate with any other devices and runs all on its own.  Let me know

John H

[Median9]

Dear John,

Thanks for the tips. I have tried almost everything without awail. Anyway, I will answer your questions as below:

1- Yes the camera gets a trigger from the CVS 5 VDC TTL which actually gets this trigger from a 24VDC Proximity sensor.

2- Yes the CVS runs independently of the PC. Stand alone mode. The parts / sec on the monitor while connected to the CVS in stand alone mode displays a much lower speed as compared to what i get while doing the benchmark.

3- When i remove the Display Image step, the flicker disapears, but the Pass/Green button turns Red/Fail if the CVS does not receive a trigger for more than the maximum timeout limit (5 sec as i have put in the setup).

4- Yes, I am running the program embedded on the CVS, where the program is set to run at startup and i have included the template image into the CVS. When on the CVS, it is completely independant from my computer at that point.

The point is, it is not only the Golden Template matching that is slowing down the CVS, there are other methods that slow it down too... like the FFT i mentioned in my last message. Even if i mask the image to my desired Field Of View, it slows down so i remove the FOV and expose some undesired parts of the acquired image just for the sake of compatibility with the higher speeds of the machine with which the CVS is attached.

I also read somewhere that while benchmarking on a PC with sample images in the PC Hard Disk, it takes longer to process where as while getting the images direct from the camera is much faster. But i am getting a complete oppsite to this.

Sincerely,

[J.Harv]

Faisal--

      How often does the trigger happen?  It sounds like if this is taking such a long time you are missing frames and trigger signals anyway.  It will miss a signal if you are doing the processing when the trigger comes, then when you wait for the next one it is adding even more time.  You might try a completely different approach.  Have a state in VBAI 3.0 that does all of the processing and at some point when a condition is met it changes state to the analysis state. This would greatly speed up the capture and rate this goes through different "parts" then the slow parts could be done separately.  If you have LabVIEW then you could send the pictures back to another computer for analysis.  Really it's just a matter of figuring out what takes such a long time and deciding if it is worth it to do or thinking about other ways to achieve the same goal. 
     Also, with such specific problems, I am sure you would get better support by actually using your support and contacting National Instruments directly.  Anyway, just let me know how things are coming along and I'd be happy to help and offer advice.

Regards,

John H

[J.Harv]

Faisal--

    I couldn't remember if I'd suggested this already... the golden template step is pretty resource intense. The thing I've noticed is that it is not always necessary, a pattern match or another step can many times be used in place.  Just a thought.

John H