From 08:00 PM CDT Friday, August 12 - 01:00 PM CDT Saturday, August 13, ni.com will be undergoing system upgrades that may result in temporary service interruption.

We appreciate your patience as we improve our online experience.

LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

get all VIs in memory across multiple LabVIEW application instances

Solved!
Go to solution

@nathand wrote:

I just tried the code below.  It is running in one project; I also have open a second project with over 300 VIs and it opens a reference to each of them without any errors.  Are you wiring the application instance reference to Open VI Reference?

open ref to each VI in all projects.png


I gave you a Kudos for the single value bundle function (which I seldom use prefering bundle by name) that solves the problem of diferent number of VIs in different projects quit cleanly. You just gave me a new tool.

 

Thank you!

 

Ben

Retired Senior Automation Systems Architect with Data Science Automation LabVIEW Champion Knight of NI and Prepper LinkedIn Profile YouTube Channel
Message 11 of 18
(3,223 Views)

@Ben wrote:

I gave you a Kudos for the single value bundle function (which I seldom use prefering bundle by name) that solves the problem of diferent number of VIs in different projects quit cleanly. You just gave me a new tool.

 

Thank you!

 

Ben


It's a nice tool and at it's place in this case, but I still think extra hard whenever I find myself having to put arrays in arrays of clusters or worse. The reason being that this is a "supercomplex" data structure with many potential problems.

 

First of all you allocate memory exponentially faster than with a single array, and don't always can see that easily.

 

Second it is an extra layer of index array and unbundle that you have to do each time you want to get at the data. For complicated manipulations later on this not only uses lots of diagramm real estate but is a real performance killer if you do that in several loops, always indexing and unbundling and possibly bundling and array inserting the result back into the array. The Inplace structure can help a bit in avoiding the worst performance issues, but it is not a supermagic sword that can do wonders.

 

For many data handling problems, coming up with a flat data structure or seperating the data into two or more seperate arrays is the better and actually more easy implemented choice as far as the actual algorithmes go that work on the data. It needs some time to untangle the data structure in your mind into smaller more manageable structures, but in the end programming on them, once you figured it out, is in fact factors easier than trying to tame the supercomplex data structure every time you need to work on it.

 

All that said I would not even start to worry about trying to do this specific problem with a different data structure Smiley Very Happy and maybe even add the project refnum into the cluster.

Rolf Kalbermatter
Averna BV
Message 12 of 18
(3,198 Views)

Indeed the data structures get complicated very quickly. But in my case, I am building a very simple program to browse through the VIs in memory and allow me to quickly change the properties of many VIs over many projects. The more complicated matter then becomes how to access different Targets in each Project, as the project's App Ref is only for the My Computer target of a project.

 

The solution I have come up with is a particularly nasty data structure that encapsulates all necessary pieces of the puzzle. And, it's not the Project ref you need to bundle, it's the Target's app ref. This later becomes the application reference for the Open VI Reference function to allow access to the VI's properties.

 

All VIs in Memory Concept.png

 

Thank you to all for your help and insight. My app is pretty awesome so far, and I hope this helps others to do great things as well.

_______________________________________________________________
"Computers are useless. They can only give you answers." - Pablo Picasso
0 Kudos
Message 13 of 18
(3,185 Views)
0 Kudos
Message 14 of 18
(3,101 Views)

@pcardinale wrote:

Try this.


It doesn't work.  In the future, you may want to read through the whole thread more carefully before posting (yes, I forget to do this too).  Your code has the same problem that the original poster did - the application reference is not wired to the Open VI Reference function.

0 Kudos
Message 15 of 18
(3,094 Views)

Hi all,

thank you all for the excellent code for finding all VIs associated with all open Projects.

 

For my work I want to find all VIs with open front panels across ALL LabVIEW instances.  

 

So, firstly, to flesh out the code discussed above I added a property node from the initial Open Application Reference that returned the App.DefaultApplication reference.  Then, I used the App.AllVIs property with this reference to return all VIs in memory associated with the default LabVIEW application instance (i.e. all VIs in memory NOT also associated with an open Project).  This combination means that I can poll every development environment VI in memory regardless of whether it is in a Project or not.

 

However, I really would like to be able to address any open executable VIs too (and every executable VI opens its own instance of the LabVIEW run-time environment), and this is proving far more challenging.

 

I have read the Knowledge Base article on communicating between the dev and real-time environments here: http://digital.ni.com/public.nsf/allkb/C32E9CD39E234DFB86256DE1007840B2

But, this approach requires knowledge of the port numbers that the dev and run-time applications (specifically, their VI servers) are using.  This is not something I know how to find out for cases where the executable VI was not created by me.

 

Does anyone know how to poll for an arbitrary (i.e. not one that you already know the VI Server port number for) executable VI application reference?

0 Kudos
Message 16 of 18
(2,503 Views)

Since VI server uses TCP/IP for this and TCP/IP has no standard way of querying available listeners other than polling the whole range of possible port numbers the answer is really no!

 

A brittle and cumbersome way would be to use Windows API calls annd identify all processes in memory, query some attributes of them to identify if it is a LabVIEW executable, determine the executables path and then read in the according INI file and parsing it for the VI server settings. In there is stated what port number the application should use for VI server.

Rolf Kalbermatter
Averna BV
0 Kudos
Message 17 of 18
(2,493 Views)

Thank you for the suggestion (and fast reply) Rolf.  From reading the article I thought something like that might be the only route to take.  I'd rather not add something so long-winded to my code so I will probably leave executable VIs out of the sphere of what my program will support for now.

 

Cheers,

Loren

0 Kudos
Message 18 of 18
(2,489 Views)