high speed image acquisition

[mjd]

Hi Eric,

Thanks for your continued advice.

I agree with your point that my embedding timing code tracks the loop time rather than the fps or time between acquired video frames. The loop time is limited either by the image get vi or by the IMAQ create vi, whichever is slower, so I think it gives a reasonable indicator of the time between acquired frames. Another option is to monitor the output of the Tracking FPS vi, which comes with an older version of Labview, keeping in mind that it does not always give accurate numbers (see below).  I modified the code to record the calculated fps, loop time and #lost frames and did some further tests using your suggested method of using ring acquisition and a various number of buffers in the ring. Here is the new code:

These are the results for a 250 ring buffer as read by the AVI readback routine I mentioned in the previous post, and then plotting the data in Excel:

I also tested ring buffers of 2500, 500, 100 and 10, all with similar drops in fps, loop time, and substantial increases in # lost frames, the latter of which rises steeply after the frame count exceeds ~ 4,000, which is only 16 sec of data at 250 fps.

For comparison, here are plots of the same indicators for a similar test of my original code (which works but has the annoying wait to preconfigure all of the buffers):

Do you have any other suggestions? It seems like I just need to stick with my original code (in the first post above).

Mike

[BlueCheese]

That is fairly odd that you see the Lost Frames counter start incrementing so early. It seems like your loop is getting a far more consistently-growing delay than I would have expected.

Looking at your code again, one thing that jumps out is some manipulation of the buffer number to extract. It looks like you reset that to 0 after you exceed the number of buffers in your ring. I think you are assuming that the buffer number is an index rather than a cumulative image number (perhaps the documentation is not clear?). You can see how it is used in the LL Ring example VI. You should simply always pass an incrementing number to this input if you don't want to skip frames. I think what could have been happening is that you start asking for older buffers and then the driver gives you different buffers once they are no longer available. I don't recall the default behavior in IMAQ but it may then wait for the next image to be acquired.

If changing the buffer number requested doesn't solve your problem, the next suggestion I'd have would be to use the VI profiler and confirm that it is the IMAQ Create VI that starts to grow in total time and not something else (like the Extract Buffer VI probably is with the old buffer number). Given that you have 32GB of RAM, I'd doubt that it would get that much slower at the number of buffers you are using before it gets slower. I'd expect some slow down as you get close to the total amount of physical memory and maybe some virtual memory swapping occurs, but not when you are only a few GB of memory in. You could also use Task Manager and verify memory consumption for the LV process and confirm that it seems to be in the right ballpark given the amount of buffers in use.

Eric

[mjd · Accepted solution]

Eric, I implemented your new suggestion and it worked just fine. I performed the same battery of tests previously described with no lost frames or drops in fps. So you were spot on. Thanks very much for all the help. The new code is shown below; I'm sure it could be more efficient, but it works.

[kapchi]

Dear Mike,

I would appreciate if you could attach your code to this thread. 

I also was wondering one thing: you are using one of the subvi's with the sign "dx". As far as I know, this is for IMAQdx. From here (https://knowledge.ni.com/KnowledgeArticleDetails?id=kA00Z0000019MEqSAM&l=en-NZ) IMAQdx is used for GigE cameras, but you have mentioned that you use camera link. Could you please clarify this? 

[myhope]

can you give me the program ? mail : mayipod@gmail.com

[SamiF]

1 comment : when acquiring at very high speed as you are doing, you can usually take advantage of not trying to display every image you acquire. Instead I suggest you send the image to the display indicator only every 30 to 40ms for instance.

1 question : why are you using IMAQ Copy to copy the buffer in the AcqBuffer image and then copy this last one to an image you'll push in your queue ? Why not directly giving the image to queue to IMAQ Copy ?

Sami