programatically selecting polymorphic vi

[James_R]

is there a way to programatically select the polymorphic instance instead of selecting manually from the dropdown in the polymorphic vi?

[kehander]

If you only need a few of the instances, you can just use a case structure in which each case contains a different polymorphic instance. Or is the situation more complicated than that?

[James_R]

I don't want to have to edit the case every time I add a new vi to the polymorphic vi. If I have to do that than there is no reason to put it into a polymorphic vi, I could just use each individual vi in a case.  I was hoping that the selector label would have a programatic control.

Ultimately I want to make an application that is generic as possible and only have a small collection of VIs that must be modified per customer.  When the developer wants to create an application for a new customer he would just create this small collection of VIs and the main logic of the application would not change.  I thought about trying to incorporate more of a config file architecture but thought this would be easier for the developer.

based on the customer flag the program could programatically select all the appropriate polymorhpic instances to run

any thoughts?

[Jarrod_S.]

LVOOP sounds well suited for this plugin architecture if you're using 8.2. You can have all your tests inherit from one generic test. Then dynamically at run-time choose which object to load and the Dynamic Dispatch terminals will automatically run the right test cases. Creating new tests simply involves inheriting extra objects from the generic parent test. You don't need to change your test framework at all!

If you don't have LV8.2, or you don't want to go in that direction, then there are a couple other simple possibilities that I see. You can use VI Server to dynamically load and execute a VI based on a path. So your user will chose a test, then your test framework loads the appropriate VI or set of VIs and executes them. The catch here is that all test VIs must have the exact same connector pane if you are going to use a Call by Reference Node. Polymorphic VIs allow for slightly different connector panes.

Finally, the most brute-force way to do this would be simply to create a number of test VIs and name them all the exact same thing, but put them in different folders. For instance, suppose all your test VIs are called foo.vi. Then write a batch file (or a LV VI) that would copy the correct version of foo.vi into the main test framework VI's directory (before the test VI has been opened) and overwrite whatever version is there. Your batch file or VI could then load the test framework VI, which would in turn load foo.vi from its own folder. It wouldn't have any clue that this may or may not be the same version of foo that it used to link to. As long as the connector panes for the foos are all compatible, the test framework VI won't complain. This would allow your customers to create custom flavors of the test program.

Message Edited by Jarrod S. on 03-29-2007 02:31 PM

[Jarrod_S.]

To answer your question about polymorphic VIs:

Polymorphic VIs are compile-time objects. They do not have any special run-time behavior, such as dynamic selection. Once you press run, they act just like any other polymorphic VI. There is also no way that I know of to switch out multiple instances at once. You do have to do it one at a time.

Polymorphic VIs are smart enough to be able to select the correct version based on the input terminal data. So, for instance, if you had a polymorphic VI with versions that accepted numeric or string data for one of its terminals, and you wire in a numeric value, the Polymorphic VI would automatically switch to the numeric version. They can't make this change at run-time, though, because the type of data flowing through a wire is fixed at run-time (LVOOP aside). It will always be numeric, or always be string. If a whole bunch of these polymorphic VIs were all wired up to the same numeric control, and you replaced it during edit mode with a string control, all the polymorphic VIs would switch. So that's one instance where the change can propagate to multiple instances, but it sounds pretty far-fetched to try to take advantage of that in your scheme,  unless there are extra details we don't know about here.

[James_R]

Thanks for the quick reply

I am using LV 8.0.1.  I need to look into LVOOP that sounds interesting.  I will try the VIserver method you described.  Thanks for all of your input!

[Jarrod_S.]

You're quite welcome. The VI Server method is very popular. Here's a link with more info on that method. In case I wasn't clear on the copy/batch file method, here's a simple example. Just open Test Setup first and run it after extracting all the files.

Here's a link with some in-depth details on LVOOP. In particular the section on the Class Design points out how to use LabVIEW classes as a plugin architecture. There's a whole lot of other information there, some of which may be useful to you, some of it not so much. It's all pretty interesting though ;).

Message Edited by Jarrod S. on 03-29-2007 03:00 PM