LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

internal memory error using IMAQ 1394 ver 2.0

Hi Robert,
I apologize for the much belated response to your e-mail.
- When I was receiving the fatal memory error I was using the GRAB vi to acquire the data.  The problem seems to go away if I switch to the SNAP acquisition method.
- I am not using the IMAQ vision FFT vi, I am using the FFT Spectrum vi.
- When the image acquisition code is removed I ran the FFT on simulated data generated within the program not loaded from a stored file.

Thanks,
Ronen

-----Original Message-----
From: support@ni.com [mailto:support@ni.com]
Sent: Monday, August 01, 2005 8:20 AM
To: Feldman, Ronen (Contractor)
Subject: Re: (Reference#7084698) Phone Support E-Mail

Hi Ronen,

My name is Robert and I am one of National Instruments' IMAQ and Vision supporters.  Eric has forwarded me your email regarding the error you are receiving as it looks like the problem may be related to the image acquisition side of things.

In your last email, you noted that the fatal error does not occur if you remove the FFT code or if you remove the IMAQ code.  I was hoping you could describe for me a couple of things in greater detail.  1) In your typical code configuration, do you acquire with a GRAB?
2) The FFT code that you mention, are you using IMAQ FFT VIs from the Vision Development Module?
3) You said if you remove the image acquisition code the program runs fine. Does this mean that you are running your code on an image loaded from file?

These answers should help us get to the bottom of the situation. Additionally, how large is your program?  Are all of the various parts subVIs?

Regarding your other question, data parameters like those that you mentioned can be changed during program execution, but those changes are not saved to the camera's configuration file.  If you make these changes through the Measurement and Automation Explorer the camera configuration file will be updated.  This behavior is to protect the configuration files from being corrupted by the program you run.

Hope this helps.  Let me know how things go with the IMAQ/FFT code.

Regards,

Note:  Your reference number is included in the subject field of this message.  It is very important not to remove or modify this reference number, or your message may be returned to you.

0 Kudos
Message 1 of 4
(2,815 Views)
Hi Ronen,
 
I guess using the forums works for me too! I'm just glad I found it Smiley Happy
 
To clarify, you are first acquiring with a Grab (does not work) or snap (works fine) and then performing an Image to Array.  After Image to array you use the intensity information within the FFT Spectrum.vi?  When the program errors out, do you know which step you are running? 
 
In addition, you should be able to whittle the program down to just these basic steps, and see if the error continues to occur.  If the problem you are having can be consistently reproduced with these three or four steps, I would be interested in seeing if I can reproduce the problem here.
 
 
Regarding one of your other questions, changes made to the camera configuration file from Labview will not be permanent.  This is to avoid the possible hazard of overwriting the file with a non working configuration.
 
Hope this helps,
 
Robert
0 Kudos
Message 2 of 4
(2,806 Views)
Hi Robert,
I have been trying to recreate the internal memory problem with little success until today.  Just as a reminder the error message that I get is:
 
Fatal Internal Error:"memory.cpp",line 638 LabVIEW Version 7.1. You will lose any unsaved work. For assistance in resolving this problem, please relaunch labVIEW, or contact NI.
 
Previously, I thought the error has to do with how images are acquired (i.e. Grab vs. a Snap) but that might not be the case since I had the code running for several hours using both methods.  When ever the code was whittled down to the minimum it worked (of course).  The code has been growing since the internal error message went away and today it reappeared after I made some trivial additions.  I was wondering if the problem might be generated if a declared local variable is used before the actual variable is executed in the code?
 
thanks,
Ronen
0 Kudos
Message 3 of 4
(2,782 Views)
Hi Ronen,
 
The local variables can be used with no problem before the variable itself is called.  Do you know where in the code you are encountering the memory.cpp error?  Is it something that can be reproduced each time you run the code?  If so, I would try running the VI in highlight execution to help identify the state of the VI prior to the error.  Additionally, are you calling any third party .dlls or other code in your program?
 
- Robert
0 Kudos
Message 4 of 4
(2,772 Views)