LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

How to Find VIs That Really Are in Memory

I've got VI references open; the references are in a variety of places in the code and most of the FPs are closed.
Now I want the code to open a new VI reference, but before I do that, I want to make sure that there won't be a name conflict.

This will give me the qualified name of the VI before I try to open it:

in.png

I thought I could use this to check what's already in memory:

pn.png

But a VI only shows up in that list if its FP is open.  If the FP is closed, it won't be in the list even though an open ref is holding it in memory.

How can I find out what VIs really are in memory (other than keeping track myself)?

"If you weren't supposed to push it, it wouldn't be a button."
0 Kudos
Message 1 of 9
(1,074 Views)

That node does return VIs in memory in the application without open FPs. Are you sure it is running in the same application instance (project)?

0 Kudos
Message 2 of 9
(1,048 Views)

@avogadro5 wrote:

That node does return VIs in memory in the application without open FPs. Are you sure it is running in the same application instance (project)?


It turns out that whether or not it works depends on the context.

ac.png

"If you weren't supposed to push it, it wouldn't be a button."
0 Kudos
Message 3 of 9
(1,009 Views)

@paul_cardinale wrote:

I thought I could use this to check what's already in memory:

pn.png

But a VI only shows up in that list if its FP is open.  If the FP is closed, it won't be in the list even though an open ref is holding it in memory.


That's just not true.

 

If I open a project, and call this method, all class member VIs will show, and their front panels are definitely not open.

 

It won't show clones though, even if the front panel is open.

 

And yes, it shows VIs in context memory. Somewhere in LabVIEW's history application instance and context seem to got mixed... The help does mention it shows VIs in application instance, but I think that help was created before the concept of contexts.

0 Kudos
Message 4 of 9
(984 Views)

wiebe@CARYA wrote:

@paul_cardinale wrote:

I thought I could use this to check what's already in memory:

pn.png

But a VI only shows up in that list if its FP is open.  If the FP is closed, it won't be in the list even though an open ref is holding it in memory.


That's just not true.

 

If I open a project, and call this method, all class member VIs will show, and their front panels are definitely not open.

 

It won't show clones though, even if the front panel is open.

 

And yes, it shows VIs in context memory. Somewhere in LabVIEW's history application instance and context seem to got mixed... The help does mention it shows VIs in application instance, but I think that help was created before the concept of contexts.


Try the code that I posted.  The VI ref is open, but the VI is not listed.

"If you weren't supposed to push it, it wouldn't be a button."
0 Kudos
Message 5 of 9
(969 Views)

@paul_cardinale wrote:

wiebe@CARYA wrote:

@paul_cardinale wrote:

I thought I could use this to check what's already in memory:

pn.png

But a VI only shows up in that list if its FP is open.  If the FP is closed, it won't be in the list even though an open ref is holding it in memory.


That's just not true.

 

If I open a project, and call this method, all class member VIs will show, and their front panels are definitely not open.

 

It won't show clones though, even if the front panel is open.

 

And yes, it shows VIs in context memory. Somewhere in LabVIEW's history application instance and context seem to got mixed... The help does mention it shows VIs in application instance, but I think that help was created before the concept of contexts.


Try the code that I posted.  The VI ref is open, but the VI is not listed.


That seems to be an update problem.

 

If you put a while loop around the Get All VIs In Memory it will return Dyn.vi at some point.

 

It seems to always update the list when I create a probe (EDIT: probe a wire, not create a new probe) in the current context.

0 Kudos
Message 6 of 9
(946 Views)

@paul_cardinale wrote:

wiebe@CARYA wrote:

@paul_cardinale wrote:

I thought I could use this to check what's already in memory:

pn.png

But a VI only shows up in that list if its FP is open.  If the FP is closed, it won't be in the list even though an open ref is holding it in memory.


That's just not true.

 

If I open a project, and call this method, all class member VIs will show, and their front panels are definitely not open.

 

It won't show clones though, even if the front panel is open.

 

And yes, it shows VIs in context memory. Somewhere in LabVIEW's history application instance and context seem to got mixed... The help does mention it shows VIs in application instance, but I think that help was created before the concept of contexts.


Try the code that I posted.  The VI ref is open, but the VI is not listed.


Also, the VI is in All System VIs In Memory, straight from the start.

 

Apparently, it's a system VI until some trigger (the probe in current context), and then it becomes a normal VI.

 

I'd concatenate System VIs In Memory and VIs In Memory, as both are probably small arrays anyways.

 

 

 

 

 

 

0 Kudos
Message 7 of 9
(939 Views)

wiebe@CARYA wrote:

@paul_cardinale wrote:

wiebe@CARYA wrote:

@paul_cardinale wrote:

I thought I could use this to check what's already in memory:

pn.png

But a VI only shows up in that list if its FP is open.  If the FP is closed, it won't be in the list even though an open ref is holding it in memory.


That's just not true.

 

If I open a project, and call this method, all class member VIs will show, and their front panels are definitely not open.

 

It won't show clones though, even if the front panel is open.

 

And yes, it shows VIs in context memory. Somewhere in LabVIEW's history application instance and context seem to got mixed... The help does mention it shows VIs in application instance, but I think that help was created before the concept of contexts.


Try the code that I posted.  The VI ref is open, but the VI is not listed.


Also, the VI is in All System VIs In Memory, straight from the start.

 

Apparently, it's a system VI until some trigger (the probe in current context), and then it becomes a normal VI.

 

I'd concatenate System VIs In Memory and VIs In Memory, as both are probably small arrays anyways.

 

 

 

 

 

 


What exactly does it mean for a VI to be a "System VI"?

"If you weren't supposed to push it, it wouldn't be a button."
0 Kudos
Message 8 of 9
(935 Views)

@paul_cardinale wrote:

wiebe@CARYA wrote:

@paul_cardinale wrote:

wiebe@CARYA wrote:

@paul_cardinale wrote:

I thought I could use this to check what's already in memory:

pn.png

But a VI only shows up in that list if its FP is open.  If the FP is closed, it won't be in the list even though an open ref is holding it in memory.


That's just not true.

 

If I open a project, and call this method, all class member VIs will show, and their front panels are definitely not open.

 

It won't show clones though, even if the front panel is open.

 

And yes, it shows VIs in context memory. Somewhere in LabVIEW's history application instance and context seem to got mixed... The help does mention it shows VIs in application instance, but I think that help was created before the concept of contexts.


Try the code that I posted.  The VI ref is open, but the VI is not listed.


Also, the VI is in All System VIs In Memory, straight from the start.

 

Apparently, it's a system VI until some trigger (the probe in current context), and then it becomes a normal VI.

 

I'd concatenate System VIs In Memory and VIs In Memory, as both are probably small arrays anyways.


What exactly does it mean for a VI to be a "System VI"?


It means the "Is System VI" property is true.

 

Or apparently that the VI is loaded in a new host context, and the context isn't updated yet 😎.

 

It has consequences for searching (system VIs are not searched, nor found, IIRC) and (IIRC) the VI Hierarchy Window (system VIs won't show up). Maybe a few other places...

0 Kudos
Message 9 of 9
(928 Views)