quick question regarding IMAQ current frame number

[Penny001]

Hi All,

I have a quick question that which vi should use if I want to know the current frame number when grabbing the images. The code I am using is an example from NI example finder called: grab and save to avi. I tried creating indicators of iteration and acquired buffer number (IMAQ grab acquire.vi) but it seems the output is not the current grabbing frame.

Any suggestions would be appreciated!!

Thank you!

[Bob_Schor]

I assume you know this example is for NI's Frame-Grabber Hardware, not for video cameras or code that uses IMAQdx.  I don't have experience with IMAQ (not-dx), so I'm sorry I can't help you.

Bob Schor

[Kemens]

In the Grab and Save to AVI.vi example, the Acquired Buffer Number should be continuously counting upward by one with each iteration (are you seeing different behavior?). 

Could you explain a bit more about what you mean by current grabbing frame?  Are you looking for a specific frame or do you care to know every x frames (eg: every 100 frames)?

[Penny001]

Thank you so much for the answer, Kemens. I connected an indicator to read the acquired buffer no. I haven't seen any different behavior. I just feel I don't really understand this so called 'acquired buffer number'. I have no idea whether there's a limitation of that number. For example, I understand it should be a circular buffer. If I don't  output my data after acquiring it, would the new data overwrite in the buffer when some threshold is achieved?  (say, after 1000 frames, the buffer start to clear itself and rewrite?)

 I ask this question just because i want to separate my data acquisition part and logging part in different while loops. So I may not want the data to be store immediately after grabbing. I may want the logging process to be hold until some point.

Thank you again, Kemens!

[Bob_Schor]

In IMAQdx (and probably also in IMAQ), you may allocate a finite numbers of Buffers in the Driver, but the Buffer Number counts strictly upward by one each acquisition.  Thus if you configure the Camera for 6 buffers, the Buffer Number will go 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, and if you now ask for Buffer 9, you'll probably get it, but if you ask for Buffer 3, you will probably either get an Error or the contents of Buffer 9, again.  It's a good idea to do an "experiment" where you acquire images at whatever rate and with however many buffers you decide to allocate, then see "how far back" you can go and still get  meaningful data.  I recommend taking a video of a Clock with a sweep second hand (tends to show "time jumps" well).  The number of buffers you actually need may be "more than advertised" ...

Bob Schor

[Kemens]

I think Bob has provided great information regarding how frame reads may work out with the method you are currently using.  I want to add on some additional thoughts to what he has already provided.

Since you mentioned you may not want the data stored immediately after they are acquired (splitting up acquisition and logging), which is a fair and valid want, I think it is worth us stepping back even further to understand the implications and costs of such requirements, and then maybe evaluate how much delay may be required between acquisition and logging. 

On the driver level, when frames are acquired, they are placed into a memory buffer, and we read from this buffer.  As a user, we do not have much control over how buffers are written to here, because it is taken care of for us already.  Whether we run into errors here or read back incorrect (overwritten) frames depends on when we make our read and also the size of our buffer.  If we want to make sure we are able to access our acquired frames until we are done with them, then we will need to make our own list/array/buffer of IMAQ image references (using IMAQ Create VI) and control what and when we write to each reference.  These image references will be under our control so we will have the responsibility of controlling when we create, write, overwrite, and dispose of them.  The size of this set of IMAQ image references will be directly dependent on how many frames you want to be able to acquire before you begin logging/overwriting them.  The key idea here is that the more frames we want to be able to have access to between acquisition and logging/disposal/overwriting, the more space we will have to set aside.  This space can either be set aside on the driver level (less control for us and requires some testing to figure out what may work out) or in LabVIEW (we have full control but also full responsibility). 

So, it might be worth understanding the purpose of having the logging process not run at the same time (or on a delayed time) that the acquisition process is running.  If this delayed time is always the same or if we have a max number of frames we will ever have to hold in delay, this should be possible to achieve, but if the number of frames we have to have access to doesn't have a cap, then we will not have a cap on the amount of memory we will need to use for our application.