Sluggish operation of LABVIEW 7.1

[unclebump]

Do you have admin privileges on the system?? Did you get an XP sp2 download??

[patelbaroda]

Listing in My setup.ini on Labview installer disk is,

[Distribution]
Title=17
GUID={E43F2D2D-5AFF-41F5-A031-6CC72E5B2EAD}
Version=7.1
IDPath=nidist.id

I tried to search in Registry using Find but it shows nothing. In fact, I can't see GUID value for any software installed. How I can see it?

I have XP service pack 2 installed and admin login.

Thanks.

[patelbaroda]

I am using IOTech's card and then initialize, read and write functions for the digital and analog inputs/outputs. There are three loops for such read/write at different places in my program. I am also using arrays to get 100 readings from analog channels. At the same time, I am using VISA serial functions for file transfer from PC to my product boards.

When I run my Vi for more then a day, then quitting from LABVIEW becomes difficult and I have to terminate it using task manager. When I open task manager at the time, I could see following files related to NI and LABVIEW

nipalsm.exe 32K

nipalsm.exe 52K

niSvcloc.exe 200K

Labview.exe 193K

running in processes.

Thanks.

[unclebump]

We need to see the code.

[patelbaroda]

There are no such entries in HKEY_LOCAL_MACHINE/software/classes.

Thanks.

[patelbaroda]

My code listing is attached here.

[Jarrod_S.]

I don't see a direct potential for a memory leak in your application, unless one is happening in one of the subVIs that you didn't include in your attachment. In general, though, you are overusing local variables in your application. You could improve overall performance significantly by using direct wire connections to transfer data and shift registers to store data. You seem to use hidden strings to store data, when a shift register would be more appropriate. You can add a shift register to a while loop or for loop by right clicking the loop frame and selecting Add Shift Register.

That would improve overall performance, because using local variables causes LabVIEW to make a copy of the data everytime you access one. Shift registers generally allow you to reuse the same buffer so that LabVIEW doesn't have to make a copy. I'm not sure why your application would slow down necessarily, unless you're dealing with some severe memory fragmentation that would affect LabVIEW's ability to allocate memory storage.

I'll link a tutorial below with some good tips on general memory management in LabVIEW and how it affects performance. These would be great to bookmark. It also has some information about profiling your VI to find out which VIs are taking up the most time or memory.

http://zone.ni.com/devzone/conceptd.nsf/webmain/732cec772aa4fbe586256a37005541d3

[patelbaroda]

Hi Thanks,

That will be the great help. I am attaching complete project here with.

Have you thought of any solution to my installation problem?

That will be another great help.

[patelbaroda]

Hi

based on the suggestion and *.pdf for memory management, I tried some optimisation of code and it looks that it is running fast compare to old version. Now I have to see is application getting slower and slower upon usage. (after 2/3 hours of continuous operation). Also I noticed that when I start the LABVIEW, it took shows around 40KB in task manager. However when it crashes, it shows around 192 MB in task manager.

Thanks.

[Jarrod_S.]

Hi,

Okay, so we are indeed dealing with a memory leak here. There are a couple things you should investigate here.

1. I haven't found any of these cases in your code, but you should definetly double check. Look for arrays that you constantly add elements to. Remember that strings are really just like byte-arrays, so make sure you aren't continually adding characters to a string (such as one of your hidden ones). Eventually that could impact memory usage.

2. I hate to blame the third party software involved here, but you might check if their DAQ driver is causing the memory leak. Try running an example that only does the DAQ part of your application (Initialize, configure, read, close, etc) in a loop. Does that cause your memory usage to saturate over time? It could be that your DAQ driver isn't releasing resources appropriately. Or maybe not... but I would do a simple test to find out.

3. If you have the Professional Development System version of LabVIEW, then you can use the profiler tools in the Tools menu to find out how much memory each of your VIs are using. If you see one using more than the others, then that will help you narrow down the memory leak.

I'm sorry I don't have any information yet on what might be causing your installation problems, but I am escalating that issue presently.