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

[nathand]

It's possible that it's not LabVIEW that's backwards, but your approach to the problem. It sounds like what you're trying to build is a tool for the development environment - you'd never run this application without LabVIEW running, right? So why not develop and distribute it internally as a LabVIEW add-on, instead of as a compiled application?

[AWebe]

Hmm, its possible that my approach is indeed backward. I admit that it is very possible. However, it just strikes me that not being able to distribute this as a compiled tool for internal use is strange.

Maybe its my skewed perspective. Maybe LabVIEW is limiting in strange ways at times. At the moment, however, I just would like to understand why it refuses to let me make a VI server connection with a compiled application. For future reference, I like to know why methods and ideas fail; thats the only way to learn.

[nathand]

---

@AWebe wrote:

Hmm, its possible that my approach is indeed backward. I admit that it is very possible. However, it just strikes me that not being able to distribute this as a compiled tool for internal use is strange.

---

Sorry, hope you didn't take my comment badly, it may not have come across the way I intended. I was just trying to say that LabVIEW, like most programming environments, has a specific way to create a tool for use within the development environment. It sounds like that's what you want to do, but for some reason don't want to do it the recommended way.

I don't know of any other programming language that makes it as easy as LabVIEW does to call a function that's not part of the application even if that function is on a remote computer. I don't see this feature as limiting or backwards, certainly compared to what other languages offer (admittedly I've barely used .NET which may have something similar).

Back to your actual code, though - have you looked at exactly where it fails or hangs, by running with execution highlighting or by removing nodes until it doesn't hang? VI Server calls definitely do work, I use them regularly in my code including in compiled applications. If you're really stuck, post your code and I'd be happy to see what I can do.

One thing to note about compiled applications: the settings from a project get copied into the INI file for the compiled application. If you have VI Server enabled for the project, then it will get enabled in the INI file for the compiled application. If you then have LabVIEW and the application running at the same time, they'll both try to open the same TCP port, which will cause problems.

[rolfk]

---

@AWebe wrote:

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

---

IMO, it is not. There is no programming environment I'm aware off that would allow arbitrary inspection and execution of functions in a compiled app, without the programmer having added that capability explicitedly in. Imagine if VI Server would allow to inspect and access every VI in an executable over remote connections. If VI Server remote access then gets enabled, anyone, including your competitor could steal your entire app and more importantly your precious test data as soon as he manages to get somehow access to the network where your executable runs on. A huge scream would go through the LabVIEW programming community if that was possible. The restrictions of which methods and properties are remote accessible is not just a nice feature but a truely necessary one, for an interface like VI Server.

And as Nathan said, what you apparently want to do is in fact a programming environment add-on. Such tools should be integrated into the programming environment not glued to it as an external app. LabVIEW has many ways to add add-ons to it. The more simple ones are fairly well documented such as dropping them either in the <LabVIEW>/wizard or <LabVIEW>/Tools directory so that they appear in the File and Tools menu respectively. Other interfaces such as project plugins are unfortunately not really documented. Apparently that is because those interfaces were more or less developed in an ad-hoc style to allow modularizing the project for NI internal groups, but no priority has been given to formalize them in a way that would be consumable by the external LabVIEW programmer. According to some internal NI sources programming project plugins can be a frustrating experience since there are many sharp edges in the interface.