From Friday, April 19th (11:00 PM CDT) through Saturday, April 20th (2:00 PM CDT), 2024, ni.com will undergo system upgrades that may result in temporary service interruption.

We appreciate your patience as we improve our online experience.

Machine Vision

cancel
Showing results for 
Search instead for 
Did you mean: 

imgSessionStopAcquisition

'imgSessionAbort' vs 'imgSessionStopAcquisition'
------------------------------------------------------------------------
There are "image roll" problems when, at high frame rates, I stop the acquisition with 'imgSessionStopAcquisition'.
What I mean is (as before) the following:
Let's look at the following scenario:
1)
I set up the grabber, this includes among others 'imgRingSetup'  (which can take "terrible" time if the ring buffer is long),
2)
I start the ring-buffered grabbing w. 'imgSessionStartAcquisition'.

Here/now it all works fine. The images are in a correct position, the real images' upper-leftmost pixel is in the upper-left corner of the acquired images.
Let's go on.


3)
I stop with 'imgSessionStopAcquisition'
4)
I start again with 'imgSessionStartAcquisition'.


But here/now, the acquired images sometimes, but not always, appear in a "rolled" position, so that the real upper-left pixel appears at e.g. the 5th pixel position of the 7th line. The top 6 lines are the last 6 lines of the previous image, the leftmost 4 columns are the rightmost 4 of the current real image from the 7th line on, the rightmost 4 of the previous real image on the first 6 lines.


This _never_ happens when I stop with 'imgSessionAbort'. But after a stop with 'imgSessionAbort' I must do 'imgRingSetup' again (having to wait the "terrible" time it can take).
The Documentation "says" that 'imgSessionStopAcquisition' does "the least needed", whereas 'imgSessionAbort' really resets everything.

 

Does somebody know a less time-consuming way to walk around it, than re-doing 'imgRingSetup'?


I look for "something mid-between", a "mix of" 'imgSessionAbort' and 'imgSessionStopAcquisition'.; i.e. that everyting except the ring-buffer definition is reset. It could be an optional  additional boolean argument to one or both of '...Abort' and "...StopAcquisition', such that if the argument is absent or present with value 'false', it's all as today. But the argument present with value 'true' would yield the "midway between" behaviour I look for: All internal counters, image-data buffers etc. reset as after today's '...Abort', but the ring-buffer setup kept, so that I need not do 'imgRingSetup' again before I start the next ring acquisition.

Don't say it could be that my camera does not (my cameras do not) fulfill some requirements  on durations of and time between field enables, line enables, etc. Facts remain: It all works fine , always, the first time and after '...Abort'  followed by 'imgRingSetup'  but not always after '...StopAcquisition' .


0 Kudos
Message 1 of 1
(3,222 Views)