I am sorry, but something like this cannot be achieved easily and will unfortunately not be possible inside the Sherlock CVB Driver as it is today.
In (meaning outside Sherlock) you could implement something like that if the *.vin driver you are using supports the IRingBuffer interface by implementing the following steps:
- Configure the number of buffers that you intend to use.
- Modify the VPAT of the individual buffers in such a way that the first
x lines of each buffer point to the last
x lines of the previous buffer (and as it is a ring buffer, the preceding buffer of the first buffer is the last buffer).
This will of course lead to the first
x lines of each buffer being inaccessible as no VPAT entries point to those lines any more. In other words: It’ll look like the first
x lines of each buffer are silently discarded and instead the last
x lines of the previous buffer will be used - if that does not fit your use case then it’ll be difficult to come up with an alternative…
- For these modifications to work properly, it’ll of course be necessary to fill the buffers strictly in rising index order (i.e. acquisition fills 0, 1, 2, …, N-1, 0, 1, … without skipping an index). Now, does not make any guarantees that this will be the case! An with manual locking, it is easy to see how a driver may deviate from this scheme as soon as it encounter a locked buffer. So for the above modification to work properly, it is essential that you refrain from using manual locking.
- Another thing that does not guarantee is the way the VPATs are allocated. If you are using a ring buffer with
N segments, a driver may either
N VPATs and use 1 or
N base pointers or…
b) use 1 VPAT and
N base pointers (which is effectively the same as calculating the base pointer based on the buffer index).
With a driver that takes approach a) the VPAT modifications as described previously will work. With a driver that takes approach b) it will not and is in fact likely to lead to access violations on accessing the first and/or last buffer.
Note that it is not uncommon for a driver to take a different approach to the driver image (i.e. the image that you call
G2Grab) on and the ring buffer images (i.e. the images that you access through
RBGetBufferImage). For example the GenICam.vin will allocate just one VPAT it uses for the driver image, but
N VPATs for the buffer images - so the described approach would work with the GenICam.vin. All the VPATs are generated just once, so any modifications made to them will persist (if e.g. the
RBGetBufferImage call would generate a new VPAT each time - which would be valid behavior - the aforementioned modifications would have to be applied repetitively).
However, honestly I don’t know if all that actually helps you or whether it is just of theoretical value because - as I already pointed out - the Sherlock driver will not do any of that…
BTW: Kudos for the image you painted!