No, we have not done a complete statistical analysis of lost frames vs speeds and sizes. We did however some of latency. "Normal operation" in any event was anything like 1280x1024 @ 500fps or 880x640 @ 1000fps, probably mentioned somewhere in the manual too.
On a general level, I'd tend to say that we have 0 frames lost in normal conditions, but a slight risk of ringbuffer overrun when system activity is unexpectedly high, usually due to high GUI activity or window redraws. Ringbuffer overrun is macroscopic and can easily be monitored and detected in the stream. What the system may suffer of, rather, is a variable latency, meaning that an image uploaded in memory by the framegrabber is not analyzed for content or stored to disk in a deterministic time. Latency is disturbing in our application, which tries to deliver some external triggers based on values of ROIs, or decides whether to write or not depending on command lines; and that is sensitive too on GUI & graphic activity. The problem is that while in Labview it is very easy to achieve concurrency, in the non-RT OS there is little one can do to avoid intermissions due to graphics, or to prioritize different asynchronous threads (only timed loops can be prioritized, IIUC).
Frame loss can be very easily checked if the camera has an option of writing its own framestamp somewhere in the image. Both the Basler A504k and the Optronis CL600x2 do. Then it is just a matter of counting framestamps. Missing that, you have to devise some other way of stamping images, e.g. with some fast-response leds cycled by different outputs of a clock divider, kept in sync with the camera. We did try to film a LCD stopwatch only to discover that the decay time of the LCD display was ~0.2 sec, providing an useless measurement (the total number of frames matching the elapsed time, to the precision of both clocks, perhaps has some value).
Our ways of measuring latency involved turning on a led visible in the image, and measuring the time delay between the command signal and the brightening of the relevant pixels as detected by the program, the number of dark frames before the turning of the led when the same command line triggered the start of recording with pretrigger (another feature of my big system), and such. And looking at the jitter of our software timestamping of each frame.
I have considered using the High Resolution Relative Seconds.vi in order to use timestamping to the µs rather than to the ms, but that would not be the point; I have no way of measuring the timepoint at which the image enters the framegrabber, and is dma'ed to memory. Programmatically, I can only register the time at which a LV call says "there is a new image to enqueue" (some framegrabber polling VI exits) and at which various other LV threads process it. Our time jitters were up to several ms anyway, and irregularly depending on GUI activity for the µs to be repeatably significant.
..actually my project is in physical volcanology: I'm studying the dynamics of multiphase conduit flows and the associated seismic and acoustic signals created by gas transport in magmatic systems. So in my experiments I need to film the ascent, expansion and burst of Taylor bubbles. And yes, this camera and the grabber are a good combination for this kind of work. I hope to achieve some results soon, also because I need to start experiments. But being my first approach to LabView, is not so immediate!
