Oldest buffer number when processing lags acquisition

[AnthonV]

Bit of a involved question:

Why is the 'actual buffer read' output from 1394 Get Image always half of 'Number of buffers' less than 'Latest buffer transferred' when the 'Oldest Buffer' mode is selected and the required buffer number is far behind the 'Latest buffer transferred'.  Should it not be 'Number of buffers' less instead of half of 'Number of buffers'? 

An example, if 'Number of buffers' is set to 20, and the 'Required Buffer' input on Get Image is 100 while the 'Latest buffer transferred' is 150, the 'Actual buffer read' output from Get Image (which should be the oldest unoverwritten internal buffer ie 130) is 140.

[Aaron B.]

Hello,

Thank you for bringing this to my attention. I have replicated the behavior that you have described. I am also puzzled by why we are seeing this. I created a small VI of my own and am having members of our R&D department investigate it further. I will let you know what they discover.

Regards,

Aaron B.
National Instruments

[AnthonV]

Thanks for the reply Aaron, I'll wait for the answer.  Reading my original question again I am just amazed that anybody could understand it as I am having difficulty with it now! 

[Aaron B.]

Apparently, it is the correct behavior.  The short answer is that the memory writing is done using a DMA channel and is controlled on the kernel level.  In order to ensure that the correct timing is maintained, half of the available buffers are reserved for DMA communication at a time.  That is why you should see this type of behavior.  I will be creating a public KnowledgeBase about this issue in the near future.  Take care!

Regards,

Aaron B.

National Instruments

[AnthonV]

Thanks for the info!

[BruceAmmons]

There is a relatively easy workaround for this problem.  I use a relatively small buffer within the firewire acquisition of about 1 second.  During the acquisition, I check for new frames acquired and transfer them to my own circular buffer of IMAQ images.  This way, I was able to maintain a large buffer of images without the half buffer penalty of the firewire buffer.  The funny thing is I did this when converting from regular IMAQ, and didn't realize I was avoiding this problem.

Bruce

[AnthonV]

Thanks for the reply Bruce, yes that will avoid this from happening.  However, as memory is fairly cheap these days and I cannot trust Labview  to service the get image VI in such a short time under Windows (say 1 second as you have it), I'm going to rather make the Firewire driver buffer fairly large so that the driver-level process ensures that no frames are lost (I think).  See I've got 6 cameras triggering simlutaniously at an average rate of 20 frames a second so I'm going to need a big buffer, especially if my IT technician decides to run a virus scan remotely on my machine without telling me!