LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

"Total Data Size" property of running VI in LabVIEW 7.1 doesn't work any more?

From the 2005 discussion, the resolution was that in LabVIEW 7.1 and later, you cannot read the memory used by a running VI.
 
I just ran both example programs posted in 2005, and no - you still cannot read the Total Data Size of a VI when it is running.  I ran both programs in LabVIEW 8.5.1. 
 
Kevin S.
Applications Engineer
National Instruments


Message Edited by Kevin_S on 07-11-2008 04:53 PM
Message 11 of 17
(885 Views)
So, how does one debug potential memory leaks or fragmentations?

We have about 2700 VIs written by four or five people, part of two or three "top-level" VIs we call over and over again, and  a very small leak, as far as I can tell by the rate of increase in the execution time and program size/memory/handles.  These are all part of an LV executable we call remotely through a crude TCP interface at the rate of 25k calls per month.  We don't even have LV on that machine.

There's got to be a way to find out where the problem is that doesn't imply staring at every single of those VIs.  And divide and conquer is a bit hard at this point, given the amount of code and associated instrumentation. 

0 Kudos
Message 12 of 17
(874 Views)
I will investigate your options and respond shortly.
 
Kevin S.
Applications Engineer
National Instruments
0 Kudos
Message 13 of 17
(841 Views)

From what I have learned, there is no direct replacement for the Total Data Size property for use with running VIs.  There are two semi-replacements, but neither one has the complete functionality of the former property node.

First, you can gather system information from the command prompt.  However, all LabVIEW information is listed under one item.  This article explains more.

Second, you can use the memory profiler tool in LabVIEW.  Tools » Profile » Performance and Memory

Note that you can also continue to use your LabVIEW 6.1 executable that functions as you want.

I hope this helps,
Kevin S.
Applications Engineer
National Instruments

Message 14 of 17
(814 Views)
Thanks for your efforts.  A couple of comments/questions.

Using cmd or task manager is so 1990s.  One can do so much better with Process Explorer, part of Sysinternals, which recently was acquired by Microsoft.  Download that utility and use it instead of the standard task manager (which is an option on one of the pull down menus).  Select a process, double click on it, and one can even see usage stats per thread, running threads, etc.  Still, it is hard to traceback from a given thread to whatever LV is doing.

On 7.1 I don't seem to thave Tools->Profile->Performance and Memory, I have Tools->Advance->Profile VIs..., which may or not be the same.  And how does one invoke such a beast from within an executable?

As far as going back to 6.1, I'm not sure we could build our code under 6.1, but it may be possible.



0 Kudos
Message 15 of 17
(805 Views)
Yes, the monitoring utility I was referring to is available at Tools » Advanced » Profile VIs on LabVIEW 7.1.  (The path I specified earlier is for later versions of LabVIEW.)  Presently, I know of no way to invoke this utility from inside a LabVIEW executable.  If I do learn of how to do this, I can update this post.
 
Kevin S.
Applications Engineer
National Instruments
 
 
0 Kudos
Message 16 of 17
(785 Views)

Just to mention another user (me) also ran into the same issue (LV 8.6). Help is clear so no time spend solving the bug...

 

However in my case I am making some (multiple) cache functions and I would like to monitor memory per cache. Not easily possible now 😞

 

About using taskmanger. There is a .Net example or so included with labview, with a good search you should be possible to find this so at least you can monitor the combined memory consumption.

 

---

25+ years long fan of LabVIEW. Be aware that NI changed their business model with great impact .
0 Kudos
Message 17 of 17
(622 Views)