Machine Vision

cancel
Showing results for 
Search instead for 
Did you mean: 

Ring acquisition when integer overflows

Hi,

I'm doing a ring acquisition using a line scan camera and the application is working fine, but I have a (not-so) theoretical question. I have an acquisition loop which closely resembles the NI-IMAQ ring buffer examples. It basically looks like this:

while (...) {
    imgSessionExamineBuffer(sid, whichBuffer, &bufferNumber, &bufferAddr);
    whichBuffer++;
}

It can be seen that whichBuffer (which is a "cumulative index") is always incremented.

My question is: what happens if whichBuffer (which is a 32-bit-integer) overflows and becomes negative? I can calculate that, with my line rate of about 2500 images per second, this will happen after roughly 10 days. This is short enough to be worried about in an industrial environment.

Thanks in advance!
Markus

0 Kudos
Message 1 of 8
(4,050 Views)
Hello Markus,

you allocate the number of buffers and if you read more images as you allocate new image will overwrite the old images.
You can finde more information to the ring acquisition here: http://zone.ni.com/devzone/cda/tut/p/id/4001#system.

Kind regards,

Elmar
0 Kudos
Message 2 of 8
(4,026 Views)
Hello Elmar,

thanks for taking the time to answer. I believe I do understand the concept of a ring buffer and that there is a finite number of buffers allocated which are overwritten after the end of the buffer is reached.

However, my question was not about the buffer itself but about the cumulative index "whichBuffer". This one is always incremented (indeed, all Microsoft C examples do this) and will overflow when the maximum value range of a signed 32-bit integer is reached. That is, the variable "whichBuffer" is incremented until it reaches the value 2,147,483,647. Then the signed 32-bit integer will wrap around and continue counting from −2,147,483,648.

My question is what the behaviour of the ring acquisition functions is when this limit is reached. My guess is that they will fail with some error, effectively limiting the number of recorded frames in one session to 2,147,483,647 without restarting the acquisition.

Best regards,
Markus
0 Kudos
Message 3 of 8
(4,024 Views)
Hello Marcus,

sorry that i misunderstood you.
You will get an error message.
Here you can finde more info:

http://digital.ni.com/public.nsf/allkb/73747B4E4A2FCBE9862568AB005E98A0?OpenDocument

Kind regards,

Elmar

0 Kudos
Message 4 of 8
(4,005 Views)
Hello Elmar,

thanks for the link. I believe the link you gave talks about the maximum number of buffers which can be in a ring simultaneously and not the maximum number of captured frames.

However, I think I will just restart the acquisition every now and then to ensure that the maximum number of captured frames (of 2^31-1) is not overflown. Maybe this could be mentioned in another knowledge base article?

Thanks again!
Markus

0 Kudos
Message 5 of 8
(4,002 Views)
0 Kudos
Message 6 of 8
(3,995 Views)
Hello Elmar,

thanks for the tip and sorry for me being so stubbornly...

Are you absolutely sure that the solution presented in the DOC file will work? Have NI devs tested this specific use case? I'm asking because, at least within the forums, I seem to be the only one who ever thought about the fact that the whichBuffer variable could overflow its range. Other people don't seem to care, probably because they either use much lower frame rates or they restart the acquisition depending on a trigger.

Let me explain my "doubts": As I understand it, the cumulative index is needed to make sure that NI IMAQ can wait for a given frame even if the buffer is already filled. E.g., if I allocate a ring buffer which can hold, say, 5 frames, I ask for frame number 0,1,2,3,4 but then after that I ask for 5,6,7 etc. I do not ask for frame 0,1,2 again after reaching buffer 4, because this would immediately return the image which is already in the ring buffer and will not wait for a new frame to arrive. But after reaching "i=2^32-1" I will ask for buffer 0 again but in this case NI IMAQ would have to wait for the new frame. Can I trust that this is properly implemented within NI IMAQ? If not, it might be better just to add a note to imgExamineBuffer() which says "note that with this function you can capture at least 2^31 frames".

Note that my doubts are only about this specific problem. Overall, I value the NI software very much and my experience with using the software has been a very pleasant one so far.

Best regards,
Markus

0 Kudos
Message 7 of 8
(3,990 Views)
Hello Marcus,

you have a buffer with 5 and you store 0,1,2,3,4 and the next image will be 5,6,7 ...... up to 2,14e^9. And the next interation you will get -2,14^9.
And that is the problem you must set the value to zero. I know that you want access for example the image 3,14e^9 and you dont want to use the new index number.
But it should not be a problem to add the max value 2,14^9 + the new index to know which image you access.
Or you create a new U64 counter value to know which image you access.

Kind regards,

Elmar
0 Kudos
Message 8 of 8
(3,986 Views)