labview runs slow after awhile

[BHTC]

Hi there. I've written an app that interacts with a motor control chip to control 2 motors. It runs ok, but after some time (say, after running overnight) LabView seems to be slowing down. Looking at the processes in windows task manager, I noticed that after the overnight run LabView was using about 50-80% of the CPU.  Also, some unrelated processes in the processes list had died being labelled "Not Responding".   After stopping and starting the LV app again the CPU was down to 2-5% usage and the execution speed was back to normal.  Any ideas? The only thing I can think of is that the "Results" display on the front panel is accumulating so many lines that it's slowing things down.  The code is attached.

Thanks Much,

Bill T.

Message Edited by BHTC on 11-02-2006 09:52 AM

[tst]

I can't look at your code, but the most likely reason is large memory consumption. If you have an array which keeps growing it will eventually force LV to keep growing the amount of memory it needs. At one point, the OS will have to start using  your hard drive as virtual memory and that would slow things down and make your CPU usage high. The display you mentioned sounds like a likely culprit. Just go over your code and make sure that you don't have places where you build arrays, strings or graph without keeping their size down.

You can also use the profiling tools in Tools>>Advanced to see where your memory consumption is.

You can look at the memory consumption of LV in the Processes tab of the task manager (assuming you're on windows).

[smercurio_fc]

One place where you have an array that keeps growing in size is your Results table. It's a 2D array of string to which you just keep inserting rows at the beginning. I don't know how many entries you end up with when running the code overnight, but this can create large memory and CPU overhead since you're telling LabVIEW to get more memory for the growing array.

[Dennis_Knutson]

Not only do you have an string that keeps growing, you are using a local variable of it in 5 different locations. That makes the memory allocation 5 times worse because each local creates a copy. Eliminate the use of locals, don't use a sequence structure, and limit the length of the string you are displaying.

[BHTC]

Ok, thanks! I'll try out those ideas.

[BillMe]

I leave the "Getting Started" window in 8.2 up most of the time and have noticed when I come to work the next day, it's like LabVIEW took a Valium and doesn't want to wake up. Takes forever for the Getting Started window to pop open from the task bar, then it takes forever to load my app. What DOES seem to work, is exiting LabVIEW and then restarting before attempting to run my app. I don't have problems like this with other apps I leave running, e.g., MS Office and others.

[Doug M]

Bill, I think what could cause a scenario like you describe where it would be faster to shut LabVIEW down and restart it rather than wait for it to reload is if you have had many files open at some point such that LabVIEW has a lot of stuff in memory, then you don't use LabVIEW for a while and eventually most of the memory is transferred to virtual memory.  When you go to use LabVIEW again, it has to reload to memory everything that was sent to virtual memory, even if at this point you only want to work with the last VI you had touched.

Message Edited by Doug M on 11-08-2006 02:43 PM

[BillMe]

That makes sense since I've noticed that even when shutting down all my VIs and leaving only the "Getting Started" window running, LabVIEW refuses to let go of all the file handles. Whether it should or not is probably a matter for debate.