How To: Reference LabVIEW VIs in Memory from a Compiled Application?

[AWebe]

Hello all! This is my first post on these boards despite the fact that I have been doing LabVIEW for almost 8 years...so go easy on me!

Basically my issue is this: I want to write a compiled application for my team to use to help us have a standardized tool to push VI help tip information. So I created a nice front panel, gave it memory storage via XML to remember info you might want to not have to type over and over again. I also gave it some formatting options, etc. Overall, a nice tool to speed up a repetitive task.

However, it runs great as a VI, but compiled does not work at all and I am sure many of you can see where this is going. I have cobbled together some snippets of code found on these boards to collect a list of references and names of all the VIs in memory that are not currently running. Then I use a ring control to parse which VI I want to target and then push the parsed and formatted help tip to that VI. But the reality is apparently that LabVIEW and a compiled application do not share the same memory allocation, because they are separate application instances.

Is there ANY way around this?

I tried one thing that seemed to make sense, but so far has resulted in the same thing. I tried to do a type def call by reference with an asynchronous call and a wait on asynchronous call function to return the reference list. However, even though this bit of code is still a VI and NOT part of the compiled code, it still somehow picks up the application instance of the owning app, and therefore does not see any of the open VIs in memory that LabVIEW controls.

Any help would be immense, as I am going nuts trying to figure this out!

Info: LabVIEW 2012.f3

I am also attaching a screen cap of the block diagram of the VI that collects the references.

Thanks in advance!

 

[nathand]

I haven't tested this, but I would try using "Open Application Reference." You will of course need to have LabVIEW running on the local computer, and configured for the main application instance to allow TCP connections on a local port. See if you can open a reference to the LabVIEW development environment this way, then pass that reference to the Application property nodes.

[AWebe]

Hmm...

I tried to open an application reference, and it works...as a VI. But again, once I compile the main code and then call that reflist VI it still picks up the compiled code's application reference, and not LabVIEW's reference. But I have never used the application reference node before. What exactly do I have to plug into it to  get it to reference LabVIEW?

Thanks for the help so far!

[nathand]

Did you wire a non-empty string to the machine name input of Open Application Reference? Even though you're connecting to the local machine, you need a valid value in that string in order to establish a TCP connection. You should be able to use "localhost" or "127.0.0.1" to refer to the local computer. If you leave that string empty or unwired, you get the local application instance, which isn't what you want. You also need the port number. It should be the same as the port you configure under Tools->Options in the VI Server category, and make sure that TCP connections are enabled there too.

[rolfk]

One small extension on this. The port configured in Tools->Options->VI Server only applies to VIs that are started in the global context (outside any project). Each project does define its own port if it wants to have VI Server access enabled and VIs loaded into a project context are accessed through that port.

[AWebe]

OK, I tried what nathand said to do. I added localhost as the string input, and added the default port of 3363 to the numerical input. This does not affect anything, except now it won't work even when not compiled. I hope I am not still doing something wrong, but I don't see what that could be. I will attach a screen grab of the block diagram for reference.

@roflk: OK, so the owning project has to be setup to use a VI server, if I understand you correctly. But how does this really effect anything? Even if the VI is part of a project, does that mean it is effectively invisible to the property node that calls all VIs in memory is we use the application reference node?

I am still so confused by this whole ordeal...I keep thinking that it should not be this hard to call a list of VIs in memory from a compiled application that was built in the application you want to reference!

Still would love any help on this topic...now it has become a point of personal pride to understand this in full.

[AWebe]

Update:

OK, I have determined the reason the list is now coming up blank. There is an error being propogated through the code due to my lack of proper error handling in this test. The error stems from trying to access the VI Server that is started by the TCP/IP settings. The error is as follows:

Property Node (arg 1) in Untitled 1
<APPEND>
Property Name: <b>Application:All VIs In Memory</b>

Error 1032 occurred at Property Node (arg 1) in Untitled 1

Possible reason(s):

LabVIEW:  VI Server access denied.

Property Name: Server:VI Access List

Seems like I have some access permission errors. Any ideas how to fix this?

[rolfk]

Well you run into a security limitation of VI server here. Many methods and properties are not possible to be accessed through a remote application instance. Any Application instance that is opened with an address is considered a remote instance. Basically if you leave the address open in the Open Application, LabVIEW shortcuts to the internal instance. If you connect some address even if it is "localhost", LabVIEW goes through the TCP/IP socket for any and all methods and proeprties and the application instance is considered a remote instance.

Open your floating help window, and place your cursor above your property. Notice the text in there: Remote Access disallowed: Yes.

The reason for this is, that if this method was available over remote connections, anyone with access to your network could connect to that LabVIEW instance and basically discover any and every VI you have currently loaded and even download them to their own computer. And this can not be fixed. This security is not possible to circumvent other than hacking into LabVIEW itself.

I guess this kills your entire idea. An executable can't connect to another executable or the LabVIEW development environment other than through a remote connection! That is due to strict process isolation rules in all modern OSes. The only possible workaround I could think is to create VIs for all remote access protected methods and properties, copying them to every LabVIEW installation you want to access with your shell (and that likely would have to be done through the network as the according methods in the VI server interface are also remote access protected) and then call those VIs through VI server.

[nathand]

There is an alternative property you can use for remote access: Exported VIs in Memory. This gets you a list of only the VIs that you are allowed to access remotely. If you configure VI Server (at least at the top-level, possibly also at the project level) to allow access to all VIs remotely, then it should work the way you want. I do not know, however, if the All Contexts property is available remotely - I don't see any documentation for it. While I have enabled scripting, I didn't modify my ini file and don't have access to that property directly at all, but I also haven't searched to see how one would get access to it.

[AWebe]

Well, I worked out why I wasn't getting any return. I had an error that was being propogated due to poor error trapping in my test VI I cobbled together. However, I also ifugred out that exported VIs is what I need, and NOT the All VIs in Memory node.

Now, I have new issues:

1) When I try to remotely call this ref list VI from my executable, the app locks up and I have to kill the task. No idea why.

2) The TCP/IP node call the LabVIEW general VI Server. However, all VIs referenced through a project have to be referenced through their own VI Server, one for each project. And I have no idea how to setup a VI server for each project, and I would have no idea how to parse through a list of all VI Servers progromatically.

So it looks like I am back to square one...

Why, oh why, does LabVIEW have to be so backwards comepared to so many other programming languages?