LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Are these Asynchronous VIs considered as open reference?

Basic info that can be skipped:

I have an application (test sequencer) that uses 2 types of reference and I seem to have a memory leak. It already uses ~700M when I call the test file and another large chunk when internal monitoring is active to save some data to file at the end. It ran out of memory throughout the weekend on a 32bit Windows. It was 1.4G in memory according to the task when I got to it on the following Monday (I expected to see 2G).

 

I wonder if the Main application is still considering as open reference when the windows are closed through user manipulation or VIs being self-closed.

 

First Asynchronous Type: Debugging windows

2 types:

Running VI: A complete VI with JKI State machine
Static Front Panel with indicators

Async Reference 1.png

Second Asynchronous Type: Multiple Clones

Async Reference 2.png

 

Thanks

0 Kudos
Message 1 of 12
(3,305 Views)

I don't know if it contributes to your problem, but my first advice is not to rely on "Abort VI" calls.  Make yourself a cleaner, more controlled shutdown mechanism.

 

Use of "Abort VI" can leave the async vi's in a weird state.  It seems plausible to me that when you use it on async clones, those clones may not get cleaned up properly, and you don't know it because the next launch creates a distinct instance of it that works.

 

 

-Kevin P

CAUTION! New LabVIEW adopters -- it's too late for me, but you *can* save yourself. The new subscription policy for LabVIEW puts NI's hand in your wallet for the rest of your working life. Are you sure you're *that* dedicated to LabVIEW? (Summary of my reasons in this post, part of a voluminous thread of mostly complaints starting here).
0 Kudos
Message 2 of 12
(3,282 Views)

If you're licensed for the Desktop Trace Execution Toolkit you should try running it (Tools -> Profile -> Trace Execution...).

 

Ben64

0 Kudos
Message 3 of 12
(3,268 Views)

I stopped using VI Server and the Run VI Method as soon as I learned about Start Asynchronous Call, which seems (to me) much cleaner and easier to manage.

 

Bob Schor

0 Kudos
Message 4 of 12
(3,247 Views)

@Kevin_Price wrote:

I don't know if it contributes to your problem, but my first advice is not to rely on "Abort VI" calls.  Make yourself a cleaner, more controlled shutdown mechanism.

 

Use of "Abort VI" can leave the async vi's in a weird state.  It seems plausible to me that when you use it on async clones, those clones may not get cleaned up properly, and you don't know it because the next launch creates a distinct instance of it that works.

 

 

-Kevin P



Thanks, that makes sense, however the white papers shows it with Abort VI 😛

http://digital.ni.com/public.nsf/allkb/68128403FC24FB6E86257211007F1104

 

What would be required to have a cleaner & controlled close?

0 Kudos
Message 5 of 12
(3,236 Views)
@ben64 wrote:

If you're licensed for the Desktop Trace Execution Toolkit you should try running it (Tools -> Profile -> Trace Execution...).

 

Ben64


 

I don't get much information out of Desktop Trace Execution Toolkit when I use it. I'm using LV2011.

0 Kudos
Message 6 of 12
(3,234 Views)

@Bob_Schor wrote:

I stopped using VI Server and the Run VI Method as soon as I learned about Start Asynchronous Call, which seems (to me) much cleaner and easier to manage.

 

Bob Schor


I did try a variety of methods, which also eventually evolved into the "Clones" code. I had issues getting the Start Asynchronous Call or maybe I just abandoned it faster than I should as the VI Server was working before I got the "Start Asynchronous Call" code working.

0 Kudos
Message 7 of 12
(3,231 Views)

That knowledgebase link does indeed use "Abort VI", but there is some not-entirely-obvious context to the question.  It's specifically for a case where a *user* needs to stop a vi when the normal methods that are provided in a GUI have been taken away.

 

A common method used to send a "shutdown" message to async code is to use a Notifier.  The async code must be programmed to catch this notification, then proceed to do an orderly shutdown.  The nice thing about using a Notifier is that it can be used as a 1-to-many mechanism to signal a shutdown to *all* the async processes at once.

 

It will be a big help to switch over to using Start Async Call as others have advised, then you can just wire in the Notifer ref to the async code modules.

 

 

-Kevin P

CAUTION! New LabVIEW adopters -- it's too late for me, but you *can* save yourself. The new subscription policy for LabVIEW puts NI's hand in your wallet for the rest of your working life. Are you sure you're *that* dedicated to LabVIEW? (Summary of my reasons in this post, part of a voluminous thread of mostly complaints starting here).
0 Kudos
Message 8 of 12
(3,184 Views)

Is there another way to force clear VIs in memory?

 

I tried plugging in a "Request Deallocation" within the main software and the clones, can't see any difference in the "Profile Performance and Memory" or the Task Manager.

 

 

0 Kudos
Message 9 of 12
(3,118 Views)

I have a suggestion for you.  Create a small, simple Project that involves starting and stopping a Clone.  Make it do something straight-forward, such as "Generate a random number once a second".  Put enough into it to clearly illustrate the problem that you are having (as without "code to examine and test", it is difficult to really understand the issue you are having).

 

When you are done, compress the folder with the Project and attach the resulting .zip file.  Please develop in something earlier than 2017 (as not everyone has installed this version, I among them).

 

I, for one, will be happy to look at and try to understand the issues you are having.  I (and probably others) may also try to modify your example using Start Asynchronous Call , as we have suggested, and see if that does the trick.  If nothing else, this should give us a much clearer picture of the problem(s) you are having with your code.

 

Bob Schor

0 Kudos
Message 10 of 12
(3,100 Views)