Programmatically get Strictly Typed VI Reference

[jon_mcbee]

I am trying to implement a plugin architecture and am starting to feel like I am missing something. I want to be able to drop a vi in a folder and incorporate it programmatically. To do this I have to use a strict type def to the plugin vi so that I can call it using a call by reference node. This seems to defeat the purpose of the plugin architecture because I have to know what the strictly type defined vi ref is in the main code. What I would like to do is to see a vi in the plugin directory, and be able to get the strictly type defined vi ref from the vi programmatically. I cannot figure out how to do this. What/where am I going wrong?

[Francois Normandin]

QUOTE (jonmcbee @ May 12 2009, 06:55 PM)

I am trying to implement a plugin architecture and am starting to feel like I am missing something. I want to be able to drop a vi in a folder and incorporate it programmatically. To do this I have to use a strict type def to the plugin vi so that I can call it using a call by reference node. This seems to defeat the purpose of the plugin architecture because I have to know what the strictly type defined vi ref is in the main code. What I would like to do is to see a vi in the plugin directory, and be able to get the strictly type defined vi ref from the vi programmatically. I cannot figure out how to do this. What/where am I going wrong?

Use "Open VI Reference" instead of "Call by Reference Node". You can call by the filepath or by name if it already in memory.

[Dan DeFriese]

QUOTE (jonmcbee @ May 12 2009, 05:55 PM)

I am trying to implement a plugin architecture and am starting to feel like I am missing something. I want to be able to drop a vi in a folder and incorporate it programmatically. To do this I have to use a strict type def to the plugin vi so that I can call it using a call by reference node. This seems to defeat the purpose of the plugin architecture because I have to know what the strictly type defined vi ref is in the main code. What I would like to do is to see a vi in the plugin directory, and be able to get the strictly type defined vi ref from the vi programmatically. I cannot figure out how to do this. What/where am I going wrong?

I don't think your missing anything. The vi typedef is so the caller knows the connector pane layout and can link the dynamic vi... This is the same principle used for DLL calls (you need to know the function prototype before you call it.) Try to standardize on a connector pane for your plugin VIs. I can think of a couple workarounds if that can't be done, but I'll ask for a few specifics first.

Of course, if your plugins don't need to accept or return values then just use the RUN VI invoke node.

~Dan

[Francois Normandin]

And you can set input values using the OpenG tools before using the "Run VI" method. That's the way I use my plugin VIs.

[PJM_labview]

QUOTE (normandinf @ May 12 2009, 07:02 PM)

And you can set input values using the OpenG tools before using the "Run VI" method. That's the way I use my plugin VIs.

I agree, the CBR is way too strict (no pun intended). I also prefer to use the run method, but I would even consider using other mechanism to pass the data to the plugin (than the set input value). The goal being to limit code change when the plugin interface changes.

By the way, if you use CBR, just create a control with the right type (connector pane) on your plugin caller and you will be ok. Of course all your plugins must have the same connector pane in that situation.

PJM

[jgcode]

The CBR node "blocks" the thread its in i.e. the called VI must complete execution before returning its outputs (which obviously makes sense) through the node.

With the Run Method you have the option to spawn a new thread.

However in the app when a new plugin command is generated, it has to unload the first VI, wait for notification from it that it has completed running (last thing it does before it goes out of memory), then launch the next plugin VI.

Otherwise if you don't wait you have potential race conditions.

Aside from passing data into out of a plugin VI, the CBR node is handy in the fact that it sequences the code.

And you can easily standardize a connector pane; Either Variant In/Out at top and Error In/Out at bottom.

This will maintain any new data added to your application.

Or you could have simply Error In/Out for each VI and load/read data from a shared resource FGV/GOOP/File etc..

But the cost of the CBR is usually another loop I have to maintain, so I am with others, and 95% of the time I spawn the VI using the Run Method.

[jon_mcbee]

QUOTE (normandinf @ May 12 2009, 08:02 PM)

And you can set input values using the OpenG tools before using the "Run VI" method. That's the way I use my plugin VIs.

In my hunting around I had not come across using OpenG with the "Run VI" method as a way to implement the plugin architecture. Could you point me towards an example, I don't know which OpenG tools you are referring to. In fact, if anyone has any good resources for the plugin type of architecture (other posts, or KB articles...) I would love to take a look at them. I literally stumbled across this architecture and have been trying to fill in the gaps as I go, if there was one place that presented all I need to know about the plugin architecture I would be beside myself with joy. I appreciate all the feedback, and welcome more if anyone has any tips they think may be useful. In the meantime I will look into using the "Run VI" method with OpenG as another way to attack this problem.

Regards

[Francois Normandin]

QUOTE (jonmcbee @ May 13 2009, 10:04 AM)

In my hunting around I had not come across using OpenG with the "Run VI" method as a way to implement the plugin architecture. Could you point me towards an example, I don't know which OpenG tools you are referring to.

It's part of the OpenG Application Control Tools. (see pic)

As PJM mentioned, there are other ways to pass input data to your plugin VI. (including Queues, Events, LV2 globals, ...) But the way I describe below is quite simple and fast. If you build your plugins with standardized control names (as long as you don't change them in the future) you will get a good way to use your plugin but I'd add that it's a good way only if you plan to initialize values and don't change them from the outside anymore. In the screenshot, I simply spawn a VI that will gather error and system messages from all the VIs that run in my app and will concatenate and display in one location. Very simple but not the sharpest design for scalability.

http://lavag.org/old_files/monthly_05_2009/post-10515-1242223877.png' target="_blank">

[jon_mcbee]

QUOTE (normandinf @ May 13 2009, 08:17 AM)

It's part of the OpenG Application Control Tools. (see pic)

As PJM mentioned, there are other ways to pass input data to your plugin VI. (including Queues, Events, LV2 globals, ...) But the way I describe below is quite simple and fast. If you build your plugins with standardized control names (as long as you don't change them in the future) you will get a good way to use your plugin but I'd add that it's a good way only if you plan to initialize values and don't change them from the outside anymore. In the screenshot, I simply spawn a VI that will gather error and system messages from all the VIs that run in my app and will concatenate and display in one location. Very simple but not the sharpest design for scalability.

It looks like this is the same method used to launch daemons. I am thinking of using the plugin architecture as a way to distribute a main code base with a different set of sub VI's, the sub VI's being the plugins, to our customers. In the past we have modified our code base per a customers request and then shipped them the code, this leaves us with countless different versions of code to support, not to mention that we have been doing it for 15 years and the code base is getting difficult to manage because it so many pieces have been hacked in over time. We are now ready to rewrite the code base and I thought that the plugin architecture may help us to avoid recreating the same problem we are fixing with the current rewrite. It seems that by breaking the code into as many plugin classes as possible and creating a generic main architecture all we have to do is ship the main architecture with the correct set of plugins to customers. In an ideal world all custom software would be developed as plugins and we would never have to touch the main code again, keeping it clean, readable and using the plugins for maintainability and scalability. I am starting to get the feeling that one mistake at the this point in development can ruin everything, and the amount of forthought necessary seems daunting. So I want to be sure that I have considered all available options before I get going.

It seems that other people must have gone down this road, assuming that what I want to do is possible. I would like to take it as far as being able to create a plugin to modify the execution of a state machine. It seems that a plugin could be created to add states to a state machine. But I am worried that what I want to do and what is possible aren't going to match up in the end.

[Francois Normandin]

QUOTE (jonmcbee @ May 13 2009, 11:04 AM)

It seems that other people must have gone down this road, assuming that what I want to do is possible. I would like to take it as far as being able to create a plugin to modify the execution of a state machine. It seems that a plugin could be created to add states to a state machine. But I am worried that what I want to do and what is possible aren't going to match up in the end.

I've read on these pages some people play with plugin architecture using LVOOP, but that's not a road I've taken myself. As such, I'll leave it to more knowledgeable people to answer you.

Have a look at this http://forums.lavag.org/Extending-LabVIEW-built-applications-with-LVOOP-plugins-t11060.html' target="_blank">topic started by Tomi Malla.

[ned]

QUOTE (jonmcbee @ May 12 2009, 06:55 PM)

I am trying to implement a plugin architecture and am starting to feel like I am missing something. I want to be able to drop a vi in a folder and incorporate it programmatically. To do this I have to use a strict type def to the plugin vi so that I can call it using a call by reference node. This seems to defeat the purpose of the plugin architecture because I have to know what the strictly type defined vi ref is in the main code. What I would like to do is to see a vi in the plugin directory, and be able to get the strictly type defined vi ref from the vi programmatically. I cannot figure out how to do this. What/where am I going wrong?

You can get a strict type reference to a specific connector pane pattern by creating a constant from the "type specifier VI refnum (for type only)" input of Open VI reference; then right-click on it the constant, browse, and select a VI with your plugin's connector pane. Now you don't need a static reference to your plugin, you just pass the appropriate path to Open VI Reference to open that specific plugin and you'll have a strict reference to it. If the connector pane doesn't match you'll get an error.

However, without knowing too much about your application, be careful of trying to make your code too generic. You'll never get your framework generic enough to cover every case without exceptions and yet still be specific enough to be useful, and is it really that much more difficult to distribute a new application than it is to distribute a new plugin? I think you're running the risk of having exactly the same problem again, just twice as complicated - you'll end up distributing lots of slightly customized plugins to your customers instead of distributing slightly modified applications. See if you can change your development process instead; for example, you might be able to use conditional disable structures for adding custom code for a particular customer. The one exception I can see here is if you absolutely cannot shut down your code in order to update it, but I'd be really hesitant about using this sort of system to do anything that critical.