Reset buffer before grab in VAS after a crash in C# Application

[trumbjd]

Hi,

I am using the Mar 2010 version of VAS in a C# application and every so often I need to terminate the application during development without shutting down the application properly.  The problem is that when I restart and try to grab a frame:

session = new ImaqSession(interfaceName);
session.Reset();

var imageType = (ImageType)session.Attributes[ImaqStandardAttribute.ImageType].GetValue();
image = new VisionImage(imageType);

bufList = session.CreateBufferCollection(1);
bufList[0].Command = ImaqBufferCommand.Loop;

session.GrabSetup(true);
session.Grab(image, true); //error here

I get an error:

"This buffer is currently protected. Release it to allow new data to be written."

If I run the Measurement and Automation Explorer and snap one frame, all is good.  So my question is: when using VAS and C#, how do I do the reset in code?  I have seen some references to doing this with the imgSessionExamineBuffer API in C, but no info with the .NET Vision components.

Any ideas???

--Jonathan

[Joe D.]

Hi Jonathan,

Is this all your code? Have you tried any of our text based vision examples? You might want to take a look at the IMAQ in c# example here:

[trumbjd]

Hi Joe,

>>Is this all your code?<<

No, but you can make this happen in your C# examples that demonstrate continuous acquisition.  Just start them up and terminate from the Windows task list.  Then try to run them again and often you will see the buffer problem.

>> You might want to take a look at the IMAQ in c# example here:<<

Did you mean to attach a reference?  Does this example show reseting the driver?

--Jonathan

[BlueCheese]

Are you running these from the IDE or as built applications? I believe for .NET applications there are some subtle differences in how the process executes.

Eric

[trumbjd]

Eric,

Currently I see the problem when running in the IDE or a standalone EXE.  In the case of the EXE, I sometimes need to kill from the task list for hung threads and such.  For the IDE, it occurs when I accidental kill the debugging host.  I only really care about the former case.  Also, I do verify that there are no abandoned threads that are actually still using the resource.

--Jonathan

[BlueCheese]

Hi Jonathan,

I'm not expert in .NET, but I believe the VAS assemblies would be what you might call "mixed-mode" as they call into native code in the IMAQ driver's DLLs. I suspect there might be some cases where proper cleanup is not occurring. In the case of running through the IDE, I think your code being debugged runs under a special process that does not close between starting/stopping the application. This would mean that normal cleanup the driver does in native code if the user's code does no cleanup on their own might not be happening because the process and DLL is not being shut down.

In the case that your application EXE being executed independently is having problems, are you explicitly closing the IMAQ sessions before closing the app?

Eric

[trumbjd]

Eric,

>>In the case that your application EXE being executed independently is having problems, are you explicitly closing the IMAQ sessions before closing the app?<<

If my application exits normally, there is no issue - I close down the session properly.  The problem is when the application can't be closed down properly.  This is an application with 10+ active threads and when something goes really haywire during development, we occasionally need to shut down the process so that the normal disposal code just doesn't get a chance to run.  The only way to get it to work again is to run the Instrument Explorer and grab a single frame from each frame grabber (we have 2).  So it looks like Instrument Explorer can do the reset, but I don't see a way to do this in the vision library.

--Jonathan

[BlueCheese]

Hi Jonathan,

There is not really any concept of "resetting the driver" in a global sense. I'm not sure exactly what is going on where MAX is able to get your system working again. In general, these types of things would be tied to the life of a specific session that is tied to a given process process. If the process dies, any resources used (including things the IMAQ driver configures in the hardware) should go back to an initial state.

Are you able to create a simple example and sequence of operations to allow us to reproduce what you are seeing here?

Eric

[trumbjd]

Eric,

Thanks, I will create a demo solution Wednesday/Thursday with directions to recreate the problem and post it.

--Jonathan