Zero to Hero: PPL Plugin Architecture in LabVIEW

Quick URL for this post: go.computerandnet.com/PPL

A plugin architecture is a common design pattern where an executable supports dynamically adding new plugins without making any code changes or rebuilding the entire application. The most common and preferred way of creating a plugin architecture in LabVIEW is by using Packed Project Libraries (PPLs).

What is a PPL?

They are project libraries that package multiple files into a single file with a .lvlibp file extension. ​

Why Not Just VIs as Plugins?

It is technically possible to use plain VIs as plugins - but it may not work in all cases. For example, if you are using a OpenG library in your VI, which was not part of your executable, the EXE will not be able to run the VI.

To avoid this and make it reliable, you would need to go with Source Distribution - which results in lot of files. Considering this a better option would be to use Packed Project Libraries (PPLs).

How are PPLs different from LLBs?

1. LLBs are editable, while PPLs are compiled code (like a DLL) and are not editable​.
2. PPLs support folder hierarchies to be maintained while LLBs don’t (which is a great help when dealing with classes)​
3. LLBs are legacy and was created during LabVIEW 8.3. ​If one file in LLB is gets corrupted, the entire LLB becomes corrupted.​
4. PPLs supports excluding dependent PPLs, which is great for plugin deployments​

Generally, PPLs are preferred over LLBs.​ PPLs are a good way of implementing plugin support to an executable and includes other advantages like:​

• PPLs are compiled binary and are hence bit faster than running in source code
• Fewer files to deploy (when compared to Source Distribution)
• Reduces build time of big monolithic application by breaking them down to component PPLs.

How to​ Use LabVIEW Classes in PPLs?

PPLs can be created only out of a top level LabVIEW library. So, is it possible to create a PPL out of a LabVIEW Class?

Yes, you can - by adding the LabVIEW Class to a LabVIEW Library and building a PPL out of the LabVIEW Library, as shown below.

For determining and loading the child classes within the PPL,

1. Get the list of PPLs in the plugin directory,
2. Get the list of classes within each PPL
3. Use the usual “Get LV Class Default Value” to load the class object.
   

LabVIEW Plugin Challenge

Download the LabVIEW Plugin Challenge from here.

Goal
We want to create an executable that can support new instrument classes as plugins. The current code has this behavior in LabVIEW development environment but not when built as an EXE.

How to Run
Open the project inside “Source” and run the “Load Instrument Plugins” VI. This would load up two instrument child classes.

The Challenge
We have given basic build specs for the different modules, which can be built. But they are not in a working condition - the built EXE will not detect any child classes. The challenge is to make the built executable exhibit the same behavior - i.e. ability to add new instrument child classes dynamically without any code change/rebuild.

Sounds interesting? Try the challenge out before proceeding to the next section.

LabVIEW Plugin Challenge Solution

Here are the steps that needs to be done to make the starter code support plugins in EXE:

1. Build the parent class PPL. Replace the parent class library with the built parent class PPL.
2. Now, build the child class and instrument manager PPLs. Replace the child class and instrument manager library with the corresponding PPLs.
3. Build and run the EXE.
4. (Optional) The updated code works only in EXE but not in source code. To make it work in source code, pass the Builds/Plugins directory path when run in source code.

Download the LabVIEW Plugin Challenge Solution from here.

Pain Points with Traditional PPL Solution

So, even though we have got the plugins to work in EXE in the above challenge, there are a few pain points:

1. The entire source code is not open as PPLs are binaries. It is difficult for debugging and testing. Not a good developer experience (DX).
2. Complicated directory structure with inter-dependencies between source code and build outputs (PPLs)
3. Complicated manual build process where you need to keep track of the order in which you run the builds.

Our Hero - LV Solution Builder

In the above LabVIEW PPL Challenge, what if I say that there is a magic tool that can straight-away make the starter code to be PPL EXE ready with zero code changes? Sounds awesome, right?

Let me introduce you to this magic tool - LV Solution Builder, an open source project architected by Phil Joffrain from NI. To this tool, you just need to give the source code directory and boom, it will take care of everything - doing in memory replacements, the order of builds and even capable of identifying code changes to determine which builds needs to happen.

Steps to Use

1. Download the latest release of LV Solution Builder LLB from github release page.
2. Inside the LLB, open the SolutionBuilder.vi. In this VI, specify the top level source code directory and run the VI.
3. LV Solution Builder will now determine the list of all projects and their build specifications and their inter-dependencies. Based on the dependencies, LV Solution Builder will determine the order of builds and execute them one by one, as seen below.
   

Advantages of LV Solution Builder

The advantages of LV Solution Builder over traditional method are:

1. Greatly improved Developer Experience (DX) when working with PPLs​ - Easier Debugging, Block Diagram of all dependencies are both viewable and editable​.
2. No code bloat/unnecessary copies.​ No Separate Workspace required for each PPL – It can all easily co-exist in a single workspace since the dependency replacements happen in memory during building​.
3. Automatically Builds in Required Order​
4. Has intelligence to skip building a component if there is no code change​ :)

GLA Summit Presentation

I had spoken about LV Solution Builder in GLA Summit 2021:

A recording of the above GLA Summit Presentation is available in YouTube.

Have you worked with PPLs in LabVIEW? Let us know in the comments :)