LVOOP class plugins in LV binary application

[Tomi_Maila]

We have a large application that uses plugins that third parties can write using LabVIEW development environment. We have both a native VI application alternative for users who have LabVIEW and binary application for users who don't. For both the native VI application and the binary application we need to have plugins that work exactly the same way in both environments and do the same thing. We have used VI folder plugins for the not binary builded LabVIEW application and builded .exe plugins for the binary application. Both plugins have been called using Open VI reference. This worked perfectly in LV 8.0 as VIs inside exe file can be opened using Open VI reference.

Now we are moving our application to LabVOOP. The intention was to create plugin classes or indeed we already have plugin classes. Each plugin would derive from a general plugin class. Each plugin would have a main VI which would just return an object of this general plugin class type. Due to the plugin nature this main VI needs to be opened using Open VI reference and then called using call by reference node.

Everything works in with native non-built plugins under LabVIEW development environment application but it seems that LabVIEW 8.20 cannot call the VI inside a binary plugin exe file any more. So our plugin system that worked perfectly for binary distributions under LV 8.0 application doesn't work under LV 8.20 any more. What would be an alternative. A DLL doesn't support returning classes as far as I understand so it is probably out of the question. We just need to be able to call a main VI that returns a plugin object and then use this object in our binary application in a environemnt that doesn't have LabVIEW development environment installed. Any ideas anybody?

Tomi

[TLE]

You can use the application builder to redirect the VI's that you were putting into an EXE into an LLB.  In theory you should then be able to use the VI server to call the VI's.  You will have to verify this.

First organize your plugin VI's into folders in the project tree if you have not done so already.  Then, in the Build Specification:

1. In the Destination section, create a custom destination for each plugin folder.  Make the sure the "Destination is LLB" box is checked.

2. In the Source File Settings section for each plugin folder check the "Set destination for all contained items" box and choose a destination created in step 1 above.

3. In the Source File Settings section for each individual VI, set the "Inclusion Type" to "Dynamic VI".  Each individual VI destination should already be chosen and grayed out (set in step 2 above).  Right now you have to do this for each individual VI, you cannot do it from the folder it is in.  I have a tech support query into NI regarding this.  For a large amount of VI's, this will be cumbersome.

Using this approach, we have been able to modularize our code into one main EXE and multiple library files.  The library files contain functions, sorta like a "DLL" approach.  We then have more configuration control which makes release testing easier.  We do have to be careful to ensure that the same VI (such as vi.lib VI's) do not end up in multiple LLB's.  This will cause VI name collisions.

I have attached an example project to illustrate this.  It is a LabVOOP implementation of a timer class by reference.

[Faraclas]

I am looking to do something similar to what TLE has suggested.  However, I need to protect the proprietary code in the generated .llb.  Previously all the code was encapsulated in the .exe file.  How can I do this with the new Object Oriented approach?

[TLE]

The diagrams are removed from the VI's put into a custom destination llb's.  However, anyone can still open the llb and then open the front panel.  This offers some copy protection at least.

[Faraclas]

TLE thanks for the heads up!  I always assumed they were regular .vi's and never thought to check.  Even better than the .llb, at least for my application, is to have the class files written to the data directory.  It turns out that all of these vi's have their block diagrams removed as well except that there is no way to open them!  It turns out that this will be an acceptable solution after all.  Thanks again for pointing this out (although I now feel like I was trying to debug a circuit without the power supply turned on!) 

Also FYI, I used your project to compare an alternate way of doing classes by reference which I suspect will be much easier to maintain especially for larger applications.  I am hoping on some feedback for performance issues, you can check out the results in the "More efficient memory management needed" thread.

[Tomi_Maila]

I wrote a blog article related to this discussion a week back.

Extending LabVIEW-built applications with LVOOP plugins

Tomi

[Ben]

For those who are interseted in laerning more about LVOOP I recomend Tomi's above linked blog with sample code.

Seeing the pieces broken out (as shown in the example) made big difference for me. It prompted me to take the plunge and start my first LVOOP project. (And I thought my applications had a lot of sub-VI's before LVOOP!)

Ben

[EWiebe]

Link not valid any more. Could you correct?

Or attach here?

Thank you.