Plug-in Architecture using Packed Project Libraries (lvlibp)

[mike_nrao]

Features

Plug-ins:

  1. Abide by a specified interface.

  2. Are independent of each other.

  3. Don’t result in name-conflicts when used in a built application.

  4. Installation is independent of main application installation.

Main Application:

   1. Is extensible without code modification to main application.

   2. Depends only on plug-in interface, not on specific plug-ins.

   3. Loads plugins dynamically.

   4. May utilizes plug-ins as UI elements or OO Design Pattern such as Strategy or Command.

   5. Requires no modification to successfully run in development or run-time environment.

   6. Installation is independent of plug-in installation.

Instructions

• Download the PowerPoint presentation to follow step-by-step how to create a plug-in architecture using packed project libraries. 
• Download 'PluginArchitecture_2011.zip' to get the source code created in the demonstration. 

The download is available for LabVIEW 2011.  If you want it in a previous version, follow the steps in the presentation to implement it yourself.

I'm interested in receiving community feedback, so please comment or ask questions.

Comments

In response to questions about displaying plug-ins in a sub-panel and communicating with message queues, I attached a version that does this in the simplest manner I can imagine:

• Communication mechanism is string messages using front panel control value change events.
• Plug-ins are given a reference to the sub-panel so they insert themselves and run using Asynchronous Call-And-Forget.
• "Exit" message (sent automatically on Panel Close event), signals the plug-in to safely end execution.

[Ravi_Beniwal]

If you are building the PPL with static calls to VIs A and B, both these

VIs will be built into the PPL and the PPL should not depend on have a copy

of either of these VIs outside the PPL.

The comment about adding an abstraction layer between your calling PPL and

PPLs containing A or B is the solution.

On Tue, May 26, 2015 at 7:08 AM CoastalMaineBird <web.community@ni.com

[CoastalMaineBird]

if you want to use one piece out of a PPL, the whole shebang has to be loaded.

I am not sure of what you try to say/do here

Basically, I'm trying to find out the rules of how to use PPLs.

It looked like, if I had a PPL with 10 VIs in it, and I want to use ONE of them, then all ten have to be loaded into memory.

I'm not sure of that now, since it looks like I can't make ANYTHING work on a PXI target.

[Jpina]

CoastalMaineBird wrote:

                       

It looked like, if I had a PPL with 10 VIs in it, and I want to use ONE of them, then all ten have to be loaded into memory.

Yes, you have to. These VIs will be part of the PPL and it will load them.

Are you trying to have VIs of the host and the PXI target within the same PPL??

[CoastalMaineBird]

If you are building the PPL with static calls to VIs A and B, both these

VIs will be built into the PPL and the PPL should not depend on have a copy

of either of these VIs outside the PPL.

Well, no, that doesn't seem to be the case.  If A and B are standalone .VI files (outside the LVLIB), (and if I do not include them in the PPL), then the PPl will call them as they are.  If one is missing, the other part of the PPL still works.

[CoastalMaineBird]

Are you trying to have VIs of the host and the PXI target within the same PPL??

That was my first thought, yes.  Just to make it easy to share these things among different installations, if there was only one file to worry about, it would be easier.

I can use a naming convention to extract the piece that I want, but it didn't work, because of error 13.

I had thought that it was the host piece that was missing dependencies, and that made the PXI piece fail, but now I'm not sure of that, since I can't make a single VI with no code and no controls work on a PXI  PPL.

[Jpina]

CoastalMaineBird wrote:

                       

Are you trying to have VIs of the host and the PXI target within the same PPL??

I had thought that it was the host piece that was missing dependencies, and that made the PXI piece fail, but now I'm not sure of that, since I can't make a single VI with no code and no controls work on a PXI  PPL.

                   

I would strongly recommend you to decouple, what belongs to the PXI belongs to the PXI and what belongs to the Host belongs to the Host.

Now, how are the host and the target sharing the PPL?

[CoastalMaineBird]

Ravi_Beniwal wrote:

                       

If you are building the PPL with static calls to VIs A and B, both these

VIs will be built into the PPL and the PPL should not depend on have a copy

of either of these VIs outside the PPL.

                   

I take it back - you are correct.  I started from scratch to prove this, and even with standalone VIs, the VI does not have to be there once the app is built.

[CoastalMaineBird]

Jpina wrote:

                       

I would strongly recommend you to decouple, what belongs to the PXI belongs to the PXI and what belongs to the Host belongs to the Host.

Not that I disagree with you (I don't), but what are your reasons?  I had thought that as long as the PXI piece was intact, within the PPL, then it wouldn't matter if the host piece was broken or not - I am ignoring it anyway.

But I'm not sure if that's wise.

Now, how are the host and the target sharing the PPL?

                   

I have logic that, when the host "attaches" the addon on the host side, a signal is sent to the PXI, with a NAME and a signature (32-bit HASH value).

The PXI looks for a PPL with that name and that signature in its own folders.  If not found, it requests a download from the host.  The host supplies the file, and the PXI stores it, with the signature.

Either way, it then tries to open a VI within the PPL, and I get error 13 when trying to get the exported path.

[CoastalMaineBird]

OK, it gets weirder. 

I made a whole new project, with a PXI target.

I made a VI called REPORT MY PATH, which simply takes CURRENT VI's PATH and returns it as a string.

I put that VI into an LVLIB.

I made a LVLIBP (PPL) from it.

I DEPLOYED the PPL.

I made a test VI to call the PPL version, and ran it.

It works (so it IS possible to use PPLs on PXI).  It reported "C:\ni-rt\startup\Report My Path.vi".

OK.

I deleted the PPL from the PXI box.

IT STILL WORKS.

I rebooted the PXI.

IT STILL WORKS.

I changed the VI to add an "XYZ" on the end.

I did NOT deploy this one.

IT STILL WORKS.  If reports the path with the XYZ, but the library doesn't exist on the PXI.

[CoastalMaineBird]

Wow, it's amzing how much I don't know about how this all works.

Can anyone explain this?

The REPORT MY PATH vi, adds an XYZ to the path string.  (To distinguish it from the one that I deployed earlier).

That is in an LVLIB, and is made into a LVLIBP.

the TEST REPORT MY PATH vi calls the REPORT MY PATH that is in the PPL.

The whole mess is under the PXI target.

When I run it, without DEPLOYING anything, it reports that its own path is in the STARTUP folder, and the VI's path is in the PPL which is in the startup folder.

OK, fine.

But the GET PATH TO EXPORTED FILE, reports that the PPL is not found.  And an FTP look, taken during the 60 second wait, shows that it's not there.

But if it's not there, how does it report the path as if it IS there?

[CoastalMaineBird]

WIthout changing the code or anything else, but just manually copying the PPL over to the PXI box, the last piece works:

In other words, if the file is really there, then all parts work as expected.

So, I wonder how it is that it works when the file isn't there...

[CoastalMaineBird]

Looks like SOME of my confusion is solved.

If you build a PPL under a PXI target, in spite of it being called a LOCAL DESTINATION directory, it doesn't put the PPL into that directory.

I had a folder called Addons as my destination, but once I moved to building under PXI, it put the new PPL in Addons\C\ni-rt\startup.  My logic doesn't look for it there, but since there was one in the place I expected, it shipped the old one over.

You can't specify "." in the TARGET DESTINATION field - it must be an absolute path.

When I account for that, things get farther along - Now it complains about the actual VI not being reentrant, but I understand that completely.

However, if I move back to building under the host, and ship that version over, it still complains about error 13, even on a VI that is empty.

It looks like there is a rule that I haven't seen written anywhere: If you want to run on a PXI, you must compile under the PXI section of your project.

[charlie87]

Hi guys,
I was reading all topic and I am not sure about a few things related to PPLs...

I have a main app compiled as PPL including LVClass interfaces and a simple exe launcher. Moreover, there are a plugin PPLs with child classes which are loaded dynamicaly from a folder when the app starts. The child classes (plugins) are accessible via a Plugin.vi which is included in the pluigin PPL. The VI returns an array of LVObject which contains the specific plugin classes. The only thing I have to do is run the Plugin.vi when pluginA.lvlibp is loaded (...\pluginA.lvlibp\Plugin.vi) and read the array.

The point is I want to minimize the app memory usage. When main PPL size is 17MB and when it is launched, the app size in system is about 250 MB. When a pluging PPL (3MB) with a few plugin classes is loaded, the app total size increases to 400 MB (???)

I am wondering, if all VIs withing PPL are loaded to memory when the children plugin class is read from Plugin.vi ? Otherwise, I want to know if Synchronous/assynchronous call VI from PPL can help ? Is there any way how to minimize the memory usage ??

[bmoyer]

I didn't expect getting a plug-in class architecture to work would be this difficult but it is.  I am able to get the example to work, but when I extend the example to something that would be helpful I run into issues that I can't get around.  So maybe someone can help.

I'm trying to make a Camera plugin architecture that calls the IMAQ driver (Vision Acquisition Software) to communicate to a camera.  I am able to send and receive responses to the camera fine, but when I want to Grab an image from the camera, my lvlibp works with my test VI in LabVIEW but it hangs in the Grab call in when running from the test exe.  My only option is to end task at that point.  What might I be doing wrong?  Do I have to do something special for VIs that call dlls?  I'm confused since communication works but not the grab which I think are the same dll.

Any thoughts?

Bruce

[Jpina]

Hi bmoyer,

I´ve never used IMAQ within my ppls before, but I called the FTDI dlls and I had no problems, have you tried to create a simple .exe of the code that you are trying to wrap woth the ppl to find out wether the problem is that the code is in a PPL or that you are forgetting any reference or something when compiling?

[BruceMoyer]

Hi Jpina, it turns out the issue most likely is with the IMAQ drivers.  But since this problem only occurs when using the plugin architecture I thought it was a problem with the architecture.  Through much debugging and contacting NI support and they were able to confirm the problem and issue a CAR #.

Here's their response:

"We think the problem may be how the VIs are loaded, since the hang seems to be occurring when we try to use the memory we've allocated for the image. We're working on finding a way to load the VI's into memory while maintaining the dynamic structure, as a troubleshooting step and as a potential workaround. Also, I apologize that I did not include the CAR # when I first mentioned it. The CAR # is 658435."

[Jpina]

Thank you for sharing the information! 😉

[Dave_Thomson]

This post (though originating a few years ago) is a great resource. Thanks for all the work you put into it, Mike, and all the follow-on comments.

I am wondering if this PPL model is still the "gold standard" for LVOOP Plug-in Architectures. Although the documents are a few years old, the thread has still be active fairly recently. I've done some searching, and from what I can tell, this architecture is still relevant. I did find another thread, though, with a discussion of using source distributions with the Actor Framework:  https://forums.ni.com/t5/LabVIEW-Development-Best/Measurement-Utility-Plugin-Hardware-Abstraction-La... (Also a great resource, Elijah!) Would anyone care to comment on how current these two architectures are, or if any other major alternatives have been devised in the last few years?

(To be a bit more explicit, the reason I am asking is because a client has a large existing LVOOP project that they want to convert to a plug-in architecture for ease of deploying new modules and fixes. AristosQ's comments on the first page of this thread make me pretty wary of going down this PPL path, but I'm definitely interested in any current opinions. We're using LV 2017.)

Thanks,

     DaveT

[mjjaeger]

All,

Apologies for tacking onto an existing/old post, but this thread best-describes what I'm currently trying to accomplish, and getting hung up on.  In short, the plugin architecture described herein is exactly what I'm looking to implement in a data acquisition/logging application.  I intend to use this to display "customizeable" plot panels depending on the type of sensor/measurement being acquired.  I have attempted to follow the excellent example provided by Mike, and believe that I have completed all of the steps appropriately, but I'm getting hung up on a very important part of the process (the "Test Run" portion).

I've setup my application a bit differently than the example, namely that: 1) I'm creating the Plugin interface and Test VI as part of the same project, and 2) I'm creating multiple Plugin*.lvlibp files within the same "Plugins" project (the "Build All" option will work great for me for the few canned examples I need).  See below (note: "Plugin-A and "Plugin-B" directories are identical):

In terms of the "Test.vi" application, I've simplified my code to essentially just start with the user specifying the location of a plugin (for example, "PluginA.lvlibp"), running in the Development environment.  The program returns Error 1498 at the "Get LV Class Default Value" VI (see below).

I've searched 100 different ways for a solution to what I'm doing wrong (I assume it's something dead-simple), but most answers pertaining to lvlibp files, plugins, and Error 1498 specifically are related to run-time (executable) challenges.  Can anyone point me to what I'm missing here?

I can upload code (LV2018 x64) if that's helpful, but couldn't find the button to do so in the new formus setup...

I greatly appreciate any suggestions you can offer!

Mark

[StefanLemmens]

Hi Mark,

since your PluginA.lvlibp : PluginA.lvclass and PluginB.lvlibp : PluginB.lvclass inherit from PluginInterface.lvlibp : PluginInterface.lvclass this is the one that needs to be in memory when they are loaded dynamically. I am suspecting that you have the development version of PluginInterface.lvclass in memory since you have the Test.vi and the PluginInterface.lvclass in the same project. My suggestion is to create a project that contains the Test.vi and PluginInterface.lvlibp and than load PluginA.lvlibp : PluginA.lvclass or PluginB.lvlibp : PluginB.lvclass dynamically casting it to more specific PluginInterface.lvlibp : PluginInterface.lvclass. So make sure the class that is on the block diagram in the Test.vi is the PluginInterface.lvclass from the packed library.

Also pay attention to exclude dependent packed libraries when building PluginA.lvlib and PluginB.lvlib.

I hope this helps. If not I'm willing to have a look at your code.

Kind Regards,

Stefan Lemmens

Intersoft Electronics