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