05-08-2012 02:58 PM - edited 05-08-2012 02:59 PM
@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?
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
05-09-2012 01:42 AM - edited 05-09-2012 01:45 AM
@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 and maybe even add the project refnum into the cluster.
05-09-2012 09:57 AM - edited 05-09-2012 10:06 AM
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.
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.
05-11-2012 02:32 PM
Try this.
05-11-2012 03:39 PM
@paul_a_cardinale 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.
11-08-2013 04:55 AM
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?
11-08-2013 09:55 AM
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.
11-08-2013 11:13 AM
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