Why does this ring operation occasionally give an error?

[DukeTom]

I am using LabWindows/CVI, and I created a low-level ring acquisition. It works normally at first, but if I stop it and start a few times (does not always happen on the first stop / start cycle), then I get the error:

NON-FATAL RUN-TIME ERROR: "Dalsa.c", line 2716, col 13, thread id 0x000012A4: Function imgSessionCopyBuffer: (return value == -1074397014 [0xbff600aa]).

The requested buffer has been overwritten and is no longer available. It occurs on the second line of the following code:

(2715) imgGetAttribute(Sid, IMG_ATTR_LAST_VALID_BUFFER, &currentRingBufNum);

(2716) imgSessionCopyBuffer(Sid, currentRingBufNum, (uInt8*)pixel_address, FALSE);

I stop my acquisition by :

imgSessionAbort(Sid, &ringBufNum);

Then I unlock my ring buffer, dispose each element, and finally dispose of the buffer list. The next acquisition starts by creating a buffer list, creating and allocating each element, locking the buffer list, and configuring the session to use that buffer list. I am NOT closing the session or the interface, I only do that upon quitting my program. Why do I get this error??

Buffer creation code:

//Create a buffer list
imgCreateBufList(NUMRINGBUFFERS, &Bid);

//Find out how big the buffers should be in memory
imgGetAttribute(Sid, IMG_ATTR_BYTESPERPIXEL, &bytesPerPixel);
bufSize = AcqWinWidth * AcqWinHeight * bytesPerPixel;

//Create the ring buffer
for (i = 0; i < NUMRINGBUFFERS; i++)
{
//Create individual buffer elements
imgCreateBuffer(Sid, IMG_HOST_FRAME, bufSize, &ringBuffer[i]);

//Now tell the buffer list where these buffers are by populating them into the Buffer List Bid
imgSetBufferElement(Bid, i, IMG_BUFF_ADDRESS, (uInt32)ringBuffer[i]);
imgSetBufferElement(Bid, i, IMG_BUFF_SIZE, bufSize);

//If we are still filling the buffer, this configures the current buffer on the list to move to the next buffer
//If we are configuring the last buffer in the list, this buffer will now loop to the first element when it is filled
bufCmd = (i == (NUMRINGBUFFERS - 1)) ? IMG_CMD_LOOP : IMG_CMD_NEXT;
imgSetBufferElement(Bid, i, IMG_BUFF_COMMAND, bufCmd);
}

//Locks the buffers in the buffer list
imgMemLock(Bid);

//Configure the session to be a ring acquisition using our buffer list
imgSessionConfigure(Sid, Bid);

Buffer disposal code:

//Unlock the ring buffer memory
if (Bid) imgMemUnlock(Bid);

//Free the ring buffer memory
for (i = 0; i < NUMRINGBUFFERS; i++)
{
if (ringBuffer[i] != NULL)
imgDisposeBuffer(ringBuffer[i]);
ringBuffer[i] = NULL;
}

//Free the buffer list
if (Bid) imgDisposeBufList(Bid, FALSE);
Bid = 0;

[DukeTom]

Additionally, after I have this problem, the camera becomes completely unusable until I restart the system!!  What is breaking so badly?  I can power cycle the camera (Dalsa Pirahna HS-40-04k40 connected by camera link to NI PCIe-1427 card), I can stop my LabWindows program, and I can try to access the camera in MAX, but I get the following error no matter what programs I close and re-open:

Error 0xBFF6001E

No acquisition in progress.

[DukeTom]

I have made some progress on narrowing the error down, but it still remains a large problem. Error trapping allows me to avoid the necessity of rebooting the system. However, I must still close and re-open my LabWindows application in order to successfully acquire from a ring.

I have narrowed the problem down to the buffer index provided by "imgSessionStatus" : on the acquisition that throws an error, it returns "-1" as the current buffer index. Why is this??

I have modified my program so that I close both the session and the interface when I hit "Stop", and yet I'm still receiving this problem when I attempt to restart the ring acquisition after stopping.  I have also started using "imgStopAcquisition" instead of "imgSessionAbort".  What could I not be properly resetting after I free, dispose and close the buffers, buffer list, session and interface?  Obviously the resource is being properly freed upon application closure, so I must be missing something ...

[DukeTom]

I thought I would post an update in case anyone else has this problem.  I have not solved it, but a work around has essentially made it a non-issue.  imgSessionStatus returning "-1" only seems to occur on the first attempted frame grab, so I simply have my frame-grabbing callback ignore any buffers returned as "-1".  On all future iterations until the acquisition is halted, imgSessionStatus returns good buffers.

Additionally, error trapping reduced this headache while I was developing and troubleshooting it.  I wrapped all IMAQ functions with:

error = imgSessionStatus(arguments);

if (error) showError(error);

Nothing new or innovative, of course, but it was helpful.