Are there ways to detect and run VI's programatically?

[flycast]

I am a text based programmer than is transitioning from text to graphical. In C# there are a couple of capabilities that I wonder exist in LabView.

1) Reflection. In C# you have the ability to get a list of classes that are included in an assembly (a program). I am wondering if I can get a list of VI's in a folder.

2) Interfaces. In C# I can define an Interface definition. It LabVIEW it would be somewhat like defining a standard for what is expected on the input and output sides of a VI.

Here is why I am wondering this. I need to write numerous tests to be run against TDMS data files. The number of discrete tests will grow over time. What I want to do is be able to define a set of inputs and outputs a that a test VI needs to have. I would write and place these VI's is a folder. My main VI would check that folder each time it opens a file to be tested and run the tests it finds in that folder and get a result for each test.

Example:

Test VI standard:

   Input:

       Array of Digital Waveforms

       Array of Analog Waveforms

   Output:

       Test Pass or fail

       Text message

The main VI would find all the VI's in a folder, try to pass the array of digital waveforms and array of analog waveforms and get a result boolean and string back. If there were two test VI's in the folder it would end up running two tests, if fifteen tests then it would run fifteen test results.

Ultimately I am trying to keep from installing new versions of my app every time I add a new test and create a way to quickly and easily deploy new tests.

Possible?

[BertMcMahan]

Yep, definitely doable. Look up "LabVIEW Plugin Architecture" for some more info. If you are running all of this on your dev computer, you can run .vi's. If you're installing this on another machine without the dev environment, your test VI's will need to be compiled into a packed project library (PPL) or executable or something (the Runtime engine can't run .vi's).

To answer your specific questions:

Regarding number 1, you can simply open a folder, list the contents, and find .vi files. You can then use VI Server to open them and run them. (You can only do this with the dev environment, not the runtime engine- see above).

Regarding number 2, yes, LabVIEW has interfaces. Look in the Help -> Find Examples for some tutorials and examples on how to use them.

Your architecture plan sounds very good. It'll be tricky for a newbie LV programmer to get right, but with your C# background it should be much simpler once you learn LabVIEW's syntax. Do note that LV Interfaces are fairly new (as in the last couple years) so some examples of plugin architectures you might find online won't use actual Interfaces. It shouldn't matter much though.

[Kyle97330]

To add on to what Bert said, I'd refer you to this page.  It's a bit old (the diagrams and screenshots were taken with an old LabVIEW version) but the theory behind it is solid.  Basically, you need to define a common connection pane that all of your VIs will follow, then open each VI in turn and run it by reference.

If you are looking for a challenge, you could also consider looking up LabVIEW's implementation of OOP, "LVOOP".  You can load classes from disk in a similar way to loading VIs, and as long as you start with the parent class in your code, any children of that class that you load later can have their methods called and then overridden by child class methods loaded later.  Again, only in the dev environment.

[BertMcMahan]

---

@Kyle97330 wrote:

To add on to what Bert said, I'd refer you to this page.  It's a bit old (the diagrams and screenshots were taken with an old LabVIEW version) but the theory behind it is solid.  Basically, you need to define a common connection pane that all of your VIs will follow, then open each VI in turn and run it by reference.

If you are looking for a challenge, you could also consider looking up LabVIEW's implementation of OOP, "LVOOP".  You can load classes from disk in a similar way to loading VIs, and as long as you start with the parent class in your code, any children of that class that you load later can have their methods called and then overridden by child class methods loaded later.  Again, only in the dev environment.

---

*Unless you compile your new code into a PPL, then you can do it in the Runtime engine. (as far as I know).

[Mark_Yedinak]

---

@BertMcMahan wrote:

---

@Kyle97330 wrote:

To add on to what Bert said, I'd refer you to this page.  It's a bit old (the diagrams and screenshots were taken with an old LabVIEW version) but the theory behind it is solid.  Basically, you need to define a common connection pane that all of your VIs will follow, then open each VI in turn and run it by reference.

If you are looking for a challenge, you could also consider looking up LabVIEW's implementation of OOP, "LVOOP".  You can load classes from disk in a similar way to loading VIs, and as long as you start with the parent class in your code, any children of that class that you load later can have their methods called and then overridden by child class methods loaded later.  Again, only in the dev environment.

---

*Unless you compile your new code into a PPL, then you can do it in the Runtime engine. (as far as I know).

---

Yes, you can run them from PPLs. Though we use classes for our PPLs. You need to be careful using PPLs though when you have dependencies. Generally, you should build them from the bottom up. You are best defining some common place for your PPLs to live if you want to be able to just drop new ones in on the go.

[BertMcMahan]

It just occurred to me we might not be super clear to the OP. To clarify:

-Classes and Interfaces in LabVIEW work like objects in other languages, no weirdness there.

-PPL's are not a type of object or anything; PPL stands for Packed Project Library, and is a way to build code similarly to an executable or DLL. A PPL can have VI's, classes, or whatever you'd like inside it. It can be very tricky to get your dependencies right if you're using objects and interfaces across multiple PPL's, but you don't have to do that if you don't want. Many example codes let you just use a common connector pane, and you can load VI's or whatever you'd like as well. It's not as snazzy as OOP but it's simpler and often you don't really need full OOP for this task anyway.

[flycast]

OK. This is what I have at this point:

This seems to run each VI from the development environment, I will need to learn how to do this from the run time environment.

Question...If I either do a directory list of vi's in a folder and run them is there a way to tell if they conform to the correct Interface specification? I will look and see how to do this in the runtime version of the same technique.

[BertMcMahan]

I believe the Run VI function will throw an error if the VI you open doesn't have the correct conpane. I don't know the error offhand, but you should be able to catch it.

[flycast]

Additional follow up question...

Is there a way to change the interface definition once it's created? I need to add a string output to all my (only 4 right now) VI's implementing the interface. I can't seem to find a way to edit the interface itself.

[crossrulz]

---

@flycast wrote:

Additional follow up question...

Is there a way to change the interface definition once it's created? I need to add a string output to all my (only 4 right now) VI's implementing the interface. I can't seem to find a way to edit the interface itself.

---

You didn't create any methods for the Interface.  That kind of defeats the purpose of an interface (to define methods).