06-13-2017 05:06 PM
Hi,
in a Labview 2015 runtime executable I get after 4 ... 8 hour a messagebox "Not enough memory to complete this operation". This is not an catchable error, only a messagebox, which stops the program execution, but not quit the program.
Can I configure the Labvie runtime environment, that the Labview Executable will quit instead of showing a Messagbox? This is an autonome measurement system and nobody will press 'OK' of the messagebox.
How can I ensure, that the program will restart after this Messagebox "Not enough memory to complete this operation". If this Messagebox block all activities in the Labview executable I can write a watchdog program which connect to a tcp server in the program, which kill the program after no answer and restart it. But it would be better, no messagebox is shown and the program quit. Then I can only watch, that the program is running in the tasklist.
Regards,
Peter
06-13-2017 06:38 PM
The real issue is why you are running out of memory. Solve that and you won't have to worry about the message box.
Also, since this should run headless, perhaps a cRIO system would be more appropriate.
06-14-2017 12:53 AM
To find the vi's which cause the Labview RTE run out of memory should discussed in an other thread.
If nobody has a solution what can I do AFTER the Messagebox is shown and stop the program execution, I make first a periodic watchdog script, which kill and restart the process.
06-14-2017 02:14 AM
@Peter_S wrote:
To find the vi's which cause the Labview RTE run out of memory should discussed in an other thread.
If nobody has a solution what can I do AFTER the Messagebox is shown and stop the program execution, I make first a periodic watchdog script, which kill and restart the process.
Since preventing the crash in the first place is the accepted way to solve this issue, it should be discussed here. Cleaning up after a crash is a poor way of handling it. (Unless, of course, you don't have permission to modify the code.)
It's probably cheaper to fix the problem in the first place, since you will probably be devoting about the same time and money to fix it than to come up with a jury-rigged "solution".
06-14-2017 02:34 AM
Any hints how to find the problem?
I use Actor Framework, Queues to pretrigger data for saving after triggering and Notifier to displa data - it is no problem to loss some data if the screen is to slow.
I tried http://zone.ni.com/reference/en-XX/help/371361H-01/lvdialog/profile/ with no success on my develop machine (Core i7, 16 GB, x64)
But the measurement system is a low power Atom Quad Core, 2 GB, x86, Win8 Embedded with enabled Unified Write Filter to prevent disk losses, because the System is on batterie.
Possible also the Unified Write Filter can run out of memory, if some files are permanently written in protected area in C:.
Unprotected is the user profile on C: and 😧 where the data are written.
Write Labview or Daqmx in other folders, ie. for logging?
06-14-2017 02:49 AM
Hi Peter,
you might want to support this old LabVIEW idea of mine 😄
But again: you should prevent this message box at all instead of trying to handle your program shutdown! Search the memory leak in your code!
06-14-2017 06:13 AM
@Peter_S wrote:
Any hints how to find the problem?
Most common memory issues are from growing and/or constantly resizing arrays. Make sure DAQmx is always reading the same number of samples each iteration. Make sure you don't have an array that just keeps getting larger and larger (often happens with GUI and graphs).
06-14-2017 06:42 AM - edited 06-14-2017 06:42 AM
Also keep in mind that strings are arrays. Evergrowing datastructures are usually the reason for memory fragmentation, which is in most cases the underlaying source of out-of-memory popups.
What is Task Manager reporting as memory consumption for the process when the popup is displayed?
Are you using 32bit LV? (kind of rhetorical....)
06-14-2017 08:30 AM
Hey,
I agree, that you should try to find the root cause for the message. Maybe you can find the cause with Tools » Profile » Performance and Memory. Even if this error does not occure on development machine, there shoud be a Vi with growing memory...
See also:
How Can I Monitor a VIs Memory Usage? - National Instruments
http://digital.ni.com/public.nsf/allkb/03553EAC5A9227B2862574F70059014E
Kind regards,
Heinz
06-14-2017 11:13 AM - edited 06-14-2017 11:14 AM
I found a possible problem with Profile Memory. The programm store all triggered data in an Array of Waveforms. After end of trigger it stores the normalized data based to the Maximum of every channel to disk. I have to change to store the raw data continuously. The Normalization can do an other program. The measurements are not so long (10..60 s) but now I have max 32 channels instead of 4, so the float waveform array is about 400 MB for 60s and in the Normalize Vi a copy is created. Nevertheless it would be very usefull to get an catchable error to see the stack trace.