Plug-in Architecture using Classes and Packed Libraries

[philip.timson]

This presentation will go through real examples of using dynamic dispatching with LabVIEW classes within packed libraries and discuss the deployment process.

• Where to use Plugin Architecture
• Demonstration
• Build and deployment process
• Why use LabVIEW Packed Libraries? Discuss the pro’s and con’s.
• Common pitfalls to avoid
• Discussion

Video on YouTube: https://www.youtube.com/watch?v=XEHPBRmDa7M

[Amiri]

Great presentation Philip, thank you.

Questions:

• Has anything changed in LV 2014 to simplify this process at all?  If so, what has changed?
• I've got all of these different FG's (I also dynamically broadcast events) throughout my system and I currently use a plugin architecture and so it looks like what I am going to have to do is put all of these FG's/dynamic events into a parent class and or parent classes in order to make this work.  Does that sound right?  Any other suggestions?

Amiri

[philjj]

Amiri,

I believe you sent this to the wrong phil ….

[philip.timson]

Hi Amiri,

Thank you for the review and questions. 

• Has anything changed in LV 2014 to simplify this process at all?  If so, what has changed?

• Unfortunately, I haven't used LV 2014 yet, but I think there are a few new features that may improve the Packed Project Library build process:

  • Excluding Dependent Packed Project and Shared Libraries from a Build Specification

    • This new feature would allow Packed Project Library build for the child class plugins to not copy the parent PPL into the build location.  That doesn't really improve the process.

  • Setting the Destinations of Packed Project and Shared Libraries You Include with a Build Specification

    • I'm wondering if this links the child PPL to a relative path of the parent PPL (I'm using "parent" in short for the PPL with the parent class and "child" for the PPL with the child/dependent class).  In the previous versions of LabVIEW, the parent PPL was assumed to be at the same location as the child PPL.  Perhaps with this new feature, the child PPL could link to the built location of the parent PPL.
  • These two new features may be able to be combined to simplify the process by skipping the step that requires you to copy the parent PPL from the \builds location to the \lib location and relink.  Although it may simplify the process, it makes the build spec more complicated.  I'm not sure if it would save much time. Either way, the build is a process and will be complicated.

• I've got all of these different FG's (I also dynamically broadcast events) throughout my system and I currently use a plugin architecture and so it looks like what I am going to have to do is put all of these FG's/dynamic events into a parent class and or parent classes in order to make this work.  Does that sound right?  Any other suggestions?

• By FG, I'm assuming you mean Functional Global. You shouldn't have to put anything into the parent class/plugin.  The purpose of the parent class/plugin is to define the interface for all the child class/plugins. 
  • Your parent class/plugin is the API you call in your application, and the child  class/plugin dynamically dispatches during run time. 
  • The only time I put code into the parent class/plugin is when there is an obvious function that EVERY child plugin will need.  Even still, it may be better practice to have a intermediate child class that all the child/plugin classes inherit from that would have the "common" methods in order to keep your parent class empty and simply be an interface class.
  • I would not recommend using functional globals at all with classes.  The variables you read/write in the functional global should just be replaced with properties read/written from the class.
  • For the events, I would recommend the following:
    • Best solution: create a register events method that happens all within the child class and encapsulates the data
    • Next best: create a common VI / library  to register the events in your application and then pass in the event reference into your classes as an input during initialization.  The parent class will need to have a method with the event reference on the front panel.  The child class would have the same method and would actually store the event reference in its properties.

Hopefully that helps.  Let me know if you have more details that would help me answer your questions more specifically.

-Philip

[philip.timson]

One other comment regarding functional globals in classes:  I've found that in many instances, accessing properties in a class is very inefficient when you are accessing large data.  Functional globals are very efficient.  In cases where I have large data in the class, I will use Data Value References and store the DVR in the class property.  I then would make an accessor that looks just like a normal read/write VI, but it is reading from the DVR. You just need to be careful when accessing the data since it is by reference.

[crabstew]

It is possible to replace a library with a packed project library dynamically, but LabVIEW definitely makes you jump through a couple hoops to do it: