How to avoid system crash when passing image via array to and from VC++ DLL?

[Kari H]

I have successfully compiled a DLL to load in and send back an altered image matrix (sent to DLL after
converted via imaqImageToArray).  When I load the labview program and it calls the DLL via the CIN, labview freezes for
a minute and then gives a memory error (have used too much) and shuts down.  There is no image subsequently sent back to lbv.
Would this be due to a problem in my VC code or is my 128MB RAM system just incapable of hadling such an operation?
I tried reducing the image to 2x2 pixels with same result.  I have been able to pass a trial matrix of numbers back and forth
in my test program.  Would it be wiser to use your IMAQ GetImagePixelPtr function to manipulate the image itself rather
than the converted array?

Thanks in advance, Kari

[Allison_S]

Kari,

    I could see several ways that that error could happen in this situation.  It is very possible that it is the 128MB of RAM, are you running Windows XP?  It's difficult to run Win XP and other programs on that much RAM.  Do you have another computer with more RAM that you can try your program on?

    Also, what format is your array when it's sent to your DLL, and exactly what format is your DLL expecting?  Errors like this can also be caused by incorrect data values being passed to/from DLLs.

    Finally, if you know the error number or more exact text for the error that would be very helpful, I can look up a lot of information based on those.  Thank you!

-Allison S.

Applications Engineering

[Kari H]

Hi Allison,
Someone is trying to load the code onto a faster computer to test it (I work from a remote location), but in the meantime I wanted to answer a few of your questions to see if the problem lies in using an incorrect data-type instead. 

First, I "misspoke" when I said CIN, I am using the CLF node.  The error I get when I run the LabView program is as follows:
"An exception occurred within the external code called by a Call Library Node.  This might have corrupted Labview's memory.  Save any work to a new location and restart Labview.
VI "--" was stopped at Call Library Function Node 0xFBC of subvi "--"."

I am using _declspec(dllexport) with a signed short datatype.  Specifically, one of my function parameters is 'signed short **imagearray'.  I have changed the image data to an array within labview first and have then sent that to my Visual Cpp program.  Since the image array is a matrix, I include the array size in my function parameters and then assign pointers to values within my C code.  I simply add 1 to each pixel value to test the code and then assign the altered image array to 'signed short **newImageArray', also included in my function's parameters.

I allocated memory using this code: 'signed short **matrix(int nrl, int nrh, int ncl, int nch)...'  and allocate pointers to rows and then allocate rows and set the pointers to them with more code.  I also use freematrix at the end of the main program to free the memory.

Am I forgetting something?
Thanks for your help,
Kari

[Allison_S]

Hi Kari,

    Thank you for all of the error information.  That error could be a memory issue, but it also very well could be a disagreement between LabVIEW and your DLL.  Something that would be worth trying; I see that when you allocate your memory you are allocating a matrix, I would try creating a simple DLL in which you send a simple 1D array to your DLL and then get it back into LabVIEW.  Then we can work up from there.  Are you running on Win XP?  Also, let me know if the code behaved any differently on the faster computer.  Finally, if there are still issues, attach the simplest LabVIEW program and DLL that still recreate the issue and I'll look them over.  Thank you!

-Allison S.

Applications Engineering

[Kari H]

Hi,
Thanks for your suggestions.  I had already written a few test programs that did link nicely to LabView and could pass and modify both arrays and single data values.  I went ahead and attached the programs that are giving me the problems so you could see what you think could be wrong.  Thanks so much,
Kari

The VC code is in this folder:
LoadImageVC2.zip

The labview programs are:
Load_Image5_VI2.vi
and ReadImageFileSub_VI2.vi (needed since is called by Load_Image5_VI2.vi)

The images you can use for the test are called(these are included in the next reply since I was limited to 3 attachments):

blackNwhite3_8bit.tiff (a black with some white test lines image normal size, 8-bit)

A_blackNwhite3_8bit.tiff.AIPD (all black with a few white test lines 8bit normal size AIPD)

If you load the Load_Image5_VI2.vi and you find you need to recompile the VC DLL for some reason, load the LoadImageVC2 program (1kB Microsoft VC solution) found in the LoadImageVC2 folder and build.

Otherwise, when you load the vi, go to the 2nd sequence structure before running and make sure that the call library function is properly configured by making sure that the library name is set to path LoadImageVC2(folder I am sending you)/debug/LoadImageVC2.dll. The getsim function should then be available to you in the box there.

Also, I set the default file options as 8-bit and the first file option as #0 (don't read raw file) so that you can load in the 8-bit tiff image file provided called blackNwhite3_8bit.tiff.
If you chose to load in the raw AIPD images that I am including to test those too, use file option #1 (read raw file).   <script></script>

Finally, before running program you do need to just click on the big 'load image' button at the top to get into the first T/F loop.

[Kari H]

Hi,
Here is the image file, the AIPD could not be uploaded and I changed the .tiff to .jpg.
Thanks,
Kari

[Allison_S]

Kari,

    Thank you for sending me all of that information and the images.  I'll look into it, but while I do, I would definitely suggest that we try and track it down together -- you are much more familiar with your code.  What changes have been made?  You said that it had worked in previous use cases, correct?  Is it just the size of the image that is different?  I may find something, but if I can't, it would be easier to work up from the programs that worked.  Let me know what you think!  Thanks!

-Allison S.

[Kari H]

Hi Allison,
Sorry my response was delayed, I did not receive the notification email that I usually do when a response has been posted.

I am attaching the test programs that I had done, basically the same that are given by NI I believe.  I worked up from there, the next program being the one
I already sent you.

The Visual C++ code is in the zipped file and the labview vi is separate.

The configuration of the CLF nodes will have to be altered based on where you store my DLL which should be in the folder with this path "C:\...\Call_Lib_Function_Test\debug".

Any help is greatly appreciated!
Thanks,
Kari

[Allison_S]

Kari,

    Thank you for getting back to me.  Have you had a chance to try and debug it at all?  I would recommend slowly working your program up to the needed point.  The sample programs work fine on my computer, so it looks like it may be a limitation of your computer, or perhaps software.  I would try working from programs you have that already work.  If, for instance, you have a program that can pass just a number to your DLL, then try to send an array with just one element, then try changing the element to be a larger number (I16 or I32).  Then try making larger arrays, etc.  The idea is to work up until some small change makes the error happen, either that or work backwards from the code that is getting the error until it stops erroring.

    We don't usually take code -- we try to help you debug your code, but even so, I can't reproduce the error so the code has to be debugged on your computer.  Try a few of the things I mentioned if you have time, or if you have any news on progress let me know and I'll do what I can to make suggestions.  Thank you!

-Allison S.

Application Engineering