11-17-2009 10:57 AM
That code looks like you could have a memory leak (based on the 2d array and guessing at what is happening in the sub-VIs).
The first step requires confirming that theory.
Follow the advice of Broken Arrow and watch the memory useage (using task manager) and if the memory climbs continually and then crashes, then its confirmed (potentially).
If its a memory leak, first review that thread I linked previously to see if you have coded the sub-VI correctly.
After taht you can start using the "show buffer allocation" tool to spot where you are creating buffers and then it becomes a game of wack-a-mole. This tag cloud for memory issues may help. If you are new to LV, and the memory issue is excaping you, don't hesitate to post more images and Q's and we will do what we can to help.
Ben
11-17-2009 12:36 PM
Hi Ben,
Thanks for your encouraging reply. I am a newbie to Labview. I tried using Window's task manager while running my VIs. CPU usage varies between 0 to 4 % when I run Main VI alone. If I start Multiplexer VI in parallel, CPU usage shoots up between 0 to 30 %.
I attached herewith snapshots of Multiplexer VI and hope it could help for sorting the problem.
Thanks
Senthil
11-17-2009 12:52 PM
We have been suspecting memory usage NOT CPU usage.
Although your posted images show that global is used, it does not tell me about your memory usage.
So re-grouping there are two things you will have to tell us if we are going to make progress.
1) Does the memory usage grow without limits and eventually a crash (T/F)
2) The application still crashes with serial port disconnected (T/F)
Please answer those questions and re-post with the update.
Ben
11-17-2009 02:16 PM
Hi Ben,
I will check it and update you soon. Shall I use 'Windows Task Manager' to check available physical memory (or) need to use any option in Labview?
I also wish to tell you that PC crash occurs after running VI for a while (approx 24 hrs) only.
Thanks
Senthil
11-17-2009 02:18 PM
851624047 wrote:Hi Ben,
I will check it and update you soon. Shall I use 'Windows Task Manager' to check available physical memory (or) need to use any option in Labview?
I also wish to tell you that PC crash occurs after running VI for a while (approx 24 hrs) only.
Thanks
Senthil
classic memory leak symptom
11-17-2009 02:43 PM
Broken Arrow wrote:
851624047 wrote:Hi Ben,
I will check it and update you soon. Shall I use 'Windows Task Manager' to check available physical memory (or) need to use any option in Labview?
I also wish to tell you that PC crash occurs after running VI for a while (approx 24 hrs) only.
Thanks
Senthil
classic memory leak symptom
Agreed!
I'll be visiting a customer tomorow so look for me.
Ben
11-18-2009 03:50 AM
Hi Senthil,
From what I can gather, it it looks like you are experiencing memory leak problems which means that your computer is unable to release memory that it has acquired. After a period of time, your computer will run out of memory and crash. As has already been mentioned by Ben and Broken Arrow, the fact that your computer crashes after about 24 hours of the VI running certainly points towards the memory leak theory. You may wish to confirm this using this link which can be used for troubleshooting memory leak issues, rather than the Windows Task Manager.
I assume that you are using the DAQmx driver for your data acquisition, which I know has been a potential source of memory leaks for customers in the past. These problems often stem from the fact that a DAQmx task is run continuously in a loop without using the DAQmx Clear Task VI, which releases any of the memory resources that the task reserved. More information on this particular issue is given here. This could be a potential source of your memory leak.
Let me know if you require further help,
Christian Hartshorne
Applications Engineering
National Instruments UK
11-18-2009 08:10 AM
Hi Ben,
I checked the memory status of PC initally by executing the Main VI alone and later checked by running multiplexer VI in parallel. Physical memory values creeps gradually in both cases as time progresses. But I am not sure of PC crash while serial port disconnected.
Thanks
Senthil
11-18-2009 09:19 AM
When dealing with intermitant issues you can really use the "patience of Job".
Something that I have learned to do is to try to establish an error rate. The process varies but reduces to trying a test out many times and watch how long and under what conditions (think the Lab notebook that Dr. Frankenstien kept). I continue until I can look my boss/customer in the eye and can tell them, it will run fine until X and by the time Y occurs BINGO!
So by watching your memory climb you are watching the condition we suspect. By waiting until memory is exhausted and corelating with the crash we can be assured that memory use is involved in the propblem.
By running with the serial disconnected we are eliminating an external factor playing a part.
It may seem that we a dragging our feet but, if we make the wrong turn on our path to a resolution, we may have to repeat or waste a lot of work.
Another reason we want to know the error rate is we need a way of deciding if we fixed it.
But now looking ahead...
Under tools >>> profile there is a Profile VIs tool that should let you locate which of your VIs is eating up memory. Once we know the VI that is hitting us we can get anal and start "wacking the moles".
Another thought!
If you have the VI Analyzer, you may want to run that against any VI that is eating memory. I believe Darren has built-in tests that check for building arrays in loop etc.
Just trying to help,
Ben
11-18-2009 09:43 AM
Senthil,
i looked into your screenshot of the FPMain and i have to confess that your code is quite a spaghetti code..... sorry to say that. This makes it hard to read and debugging not an easy job, esp. when looking for race conditions or memory leaks.
That being said and taking into account that you are seeing an increasing need for memory of your VI, you should check the code for indefinetly growing arrays. To be honest, i've never seen a PC to "bluescreen" (is this a valid verb?) when an array got too large, but we never know....
Reasons i am used to bluescreens are access to invalid memory spaces due to invalid references or trying to access dataspace which is already freed by the system. None of these two reasons require a memory leak for the crash (but they more likely occur if a leak is present!).
So you should also take a look into your interface-handles (serial, DAQ, FP) and check if the crash occurs only when they are changing (hopefully, you will see the change before the crash, but this is only a hope!)
Btw: I encountered those bluescreens (NULL address) mainly when having bad RAM, overheat issues or a broken graphic device......
hope this helps,
Norbert