nipalsm.exe memory leak?

[alejandroandreatta]

I have a system to collect voltage data using an NI-PXI 1011 chassis and two NI-PXI 4060 DMMs. When I start the computer three nipalsn.exe show up in the process viewer using 3, 6, and 10 Mb of RAM respectively. After my program is running for several days nonstop, one of the nipalsm.exe processes balloons to 90Mb of RAM and is still growing. The memory use for my program is relatively constant the entire time (it goes up and down a few megs depending on how many data points is collecting.)

This memory problem, by the way, is happening on FIVE simmilar computers running the same software/ hardware combination.

I am using the latest drivers that came with the 1st quarter 2009 developer suite (i.e. NI-PAL 2.4, NI-VISA 4.4.1, NI trad DAQ 7.4.4, ...) My standalone program is written with LV 8.6.1.

Questions:

Why three nipalsm.exe processes?

Why the out of control memory increase?

What installs NI-PAL? I could not find the individual installer for it (so I could try to reinstall it).

Thanks for your help.

Alejandro

[Jordan F]

Hi Alejandro,

It is expected to have multiple instances of nipalsm if you are running multiple different drivers. When I start my computer I also have three nipalsm.exe tasks that show in the task manager.   

I See Multiple Instances of nipalsm in the Windows Task Manager after Installing New NI Driver Software
http://digital.ni.com/public.nsf/allkb/1212376A1C10A99B86256D12006C79EA?OpenDocument

There is no installer for NI-PAL specifically because it is a driver that is installed by many NI software products.  So, if you have the latest drivers you should have the latest NI-PAL version on your system.

I do not know right off what is wrong in your system but it is likely related to your program since this is happening with multiple other systems.  Have you tried running example programs to see if you have the same behavior?  Are you making sure that all of your tasks are getting closed properly in your program?  How are you writing the acquired data to the file?

It would be helpful if you could elaborate a little more of how your program is set up and if you have any other tasks running besides your two DMMs.  Also, what is the controller you are running?  If you are using MXI what is the computer you are using to run the PXI chassis?   

[alejandroandreatta]

HI Jordan,

Thanks for your suggestion an link regarding the mutliple niplasm.exe processes. I looked at mi code for another week after your comment regarding closing tasks and here is what I found.

I have attached the subvi that has all the NI-Switch and NI-DMM code. The full program is quite large and has ~120 sub vis. It collects data from 400 light emitting diodes and the subvi (Dual DMM and Switch Scanning4.vi) can run 0 - 200 times per hr depending on what stage the diodes are at.


I believe that all the tasks are getting closed properly. But I cannot tell if there is somthing wrong with the vi.

Another piece of information that points to Dual DMM and Switch Scanning4.vi likely being the culprit is that we have 3 additional data collection systems that do not exhibit the problem with nipalsm.exe growing out of control. In those systems we use Keithley multiplexers and multimeters instead of NI hardware. The software used is identical in every respect except that when it goes to get the data it uses a different subvi that talks to the Keithley gear via GPIB. In this case the nipalsm.exe memory use does not change over time.


The ultimate problem that I have is that the data collection can run for many days without problems and then, suddenly, it will lockup. The computer will be fine and I can access other programs in the system, but my LV program gets stuck acquiring data. In fact the main program has two while loops, one to handle the user interface and the other to do data collection. Only the data collection loop hangs. After months of looking at the code and other parameters, I noticed the niplasm.exe processes memory mushrooming over time.


Any suggestion will be appreciated.

Alejandro