Need Advice about PPL Usage

[CoastalMaineBird]

LV 2013, LVRT 2013 (PXI), Win 7

I'm an old hand at LabVIEW, but I'm new to using Project Libraries (.lvlib) and Packed Project Libraries (.lvlibp).

I'm hoping someone with more experience can offer some insight and guidance.

At first blush, it looks like PPLs can solve a problem of mine.

My project is large: 500 channels from 20+ different domains: plugin boards, networked devices, etc.  Lots of data analysis and reporting.  There are 30+ cells with a copy of this, it has to be EXE and RTEXE files, not just LabVIEW DevSys.

It's been working for 10+ years, we are now doing a rewrite, so that DAQ is happening all the time, rather than on demand.

My client wants to have "addons", so that when a new Gizmotron 9000 comes along, we don't have to add to the main program, we write an "addon" to handle the Gizmotron.  This "addon" would have a UI, and be able to share VIs from the main host, and data, but not require any changes to the host code. Eventually, these should be capable of being written by someone other than me, an engineer (in some other field) with fewer LabVIEW skills than me.

Using a VI for this would work, but is kind of fragile.  If this VI uses a VI in the host, then it's path-dependent.  Moving the VI to a different folder would at best, cause a SEARCH box to come up, and at worst, break things.  I'm not even sure if the SEARCH box would come up, in an EXE.  And if I want a given host VI to be available to these addons, I have to make sure that it's not stripped by the BUILD process.

So, I looked at making a DLL. Yuck. Double Yuck.  I'm not about to make the client have to edit C header files, just making the "wizard" import a DLL that it just made is a nightmare. 

So, i found PPLs.  It looks like they're the answer.

I've already implemented a system where a given PPL has a "Description" VI, and a "Work" VI. If you choose a given PPL, it runs the "Decription" VI and obtains a text decription (that the maker writes) of what the package does.  If you choose this one, then it takes the "Work" VI, creates a new window with a subPanel to fit, and installs the "Work" VI in it. A string notifier sends messages to it.  The host provides Preferences save / restore functions.  The window can be hidden and shown. It can do anything as far as UI that it needs.  

I can move the PPL from the ADDONS folder to the ADDONS\GoodStuff\2015\May folder.  My menu system will offer it, and if you choose it, it still works. It is self-contained, it just works.

But being self-contained has a "small" downside.  I have a fair number of FGVs: Functional Global Variables.  I call them "managers" - the idea is that they keep info in Shift Registers, and a caller calls them with some function to perform using that info.

For example, one might keep a TCP Connection ID in such a ShiftReg and have CONNECT, DISCONNECT, and various SEND and RECEIVE functions which use that ShiftReg.

Without attention, that pattern doesn't survive the move to PPLs.  Because of the "self-contained" aspect, there are actually TWO instances of the manager, with TWO separate dataspaces. So, if the host calls it, and the PPL then calls it, they don't share the same info.

Here's where my understanding of this gets dicey.  If I create a separate PPL just for this manager, then that's an answer.  If everybody calls the PPL version, then there will only be one instance, and all is well.

But what's the best way to do that?

I can put the LVLIB into the master project, and then add a Build Spec to make the LVLIBP, I found out I have to actually put the PPL itself into the project to get it to work.  But that means there are TWO copies of the VI in the project.  The only way I can get it to work is to specify to use the copy from the PPL, and NOT use the one that's in the host already.

So, to avoid temptation, should I move all these manager things into one separate project?  Should I move them into individual separate projects?  Should I just remove the components from the main project after building the PPL? (no, I can't do that - that would make it impossible to update the PPL).  What's the best strategy, and why?

Another thing I don't understand is the physical handling of the PPL.  Does it have to actually exist?  

Apparently not - I did a test:

--- Create a LVLIB for one of these managers.  It lives in the ADDONS folder.

--- My HOST code (in an EXE) initializes it, and stores a value.

--- One of the ADDONS from a PPL reads that value and displays it.

--- It works.  The data is shared.

--- I moved the PPL file to a different folder, inside the ADDONS folder.  It works.

--- I moved the PPL file to my desktop.  IT STILL WORKS.

--- I changed the PPLs file name .  IT STILL WORKS.

--- I deleted the PPL file.  IT STILL WORKS.

So, apparently the PPL was incorporated into the EXE.  But I didn't specifically include it - the only SOURCE code I specified was the host main VI.

Is that what happened? Am I understanding it right?

But if that's what happened, then how does a stand-alone PPL know that it's there?  Because my standalone PPL accessed it just fine, even though it's in an EXE.

Do I have to deploy the PPL file alongside the EXE? or just ignore the thing.  I just don't quite understand how it works.

[Sam_Sharp]

For your FGVs, they all need to go into their own 'shared' PPL and you need to call the version from within the PPL in both your main application and within your plugins. Just put them all into a library and then create a PPL from that, no need to remove them from the project but you must make sure that you call the one from the PPL everywhere.

[CoastalMaineBird]

This bit of help text, from the USING PPLs in LabVIEW PROJECTS topic. is not helpful:

If a stand-alone application, a shared library, or a packed library calls a VI in a packed library, include the packed library in the same directory as the other build specifications.

I don't understand that.  Build specs are not in directories, so what does " in the same directory as the other build specs" mean?

[CoastalMaineBird]

Just put them all into a library and then create a PPL from that, no need to remove them from the project but you must make sure that you call the one from the PPL everywhere.

So, you just live with the temptation, and force yourself to call the PPL one instead of the "regular' one?

Is that easier than it seems?

[CoastalMaineBird]

you need to call the version from within the PPL in both your main application and within your plugins

At run time, does that PPL have to exist alongside the host, or alongside the plugin, or at all?

My first test indicates that the file doesn't even have to exist at run time, but that starts to look like magic, which I can't use without an explanation.

[Sam_Sharp]

It needs to be external to your application so that your plugins can also reference it (otherwise it'll get automatically sucked into the executable as a dependency). So put it in the 'always include' and then put it somewhere sensible in the build specification output. The path will probably be important so that the plugins also know where to find it (hence suggestion of putting the shared PPL in the same folder as your plugins).

[CoastalMaineBird]

---

@Sam_Sharp wrote:

It needs to be external to your application so that your plugins can also reference it (otherwise it'll get automatically sucked into the executable as a dependency). 

---

Apparently, it got "automatically sucked in".  But yet, the plugin still found it, even after I deleted the PPL file.

---

@Sam_Sharp wrote:

The path will probably be important so that the plugins also know where to find it (hence suggestion of putting the shared PPL in the same folder as your plugins).

---

But if the path is important, then this is not solving one of my problems, the portability of the addons.

[CoastalMaineBird]

If it's in the same project, then I get errors when I try to rebuild the PPL:

The build was unsuccessful.  LabVIEW cannot build packed libraries that are in memory. Error 1051.

Even if I remove the PPL from the project, I get this error.  I don't know why it's "in memory".

[CoastalMaineBird]

Wow.  Even when I removed the PPL from the project, I cannot rebuild it, because "It's already in memory".

Even if I quit and restart LabVIEW,  "It's already in memory".

I have to remove all calls to the PPL from my code, and THEN I can rebuild it.

That makes it darn near unusable.

[Hooovahh]

---

@CoastalMaineBird wrote:

But if the path is important, then this is not solving one of my problems, the portability of the addons.

---

If your problem is "how do I find plugins not included in my EXE as a plugin architecture".  By relative path is the only simple method.  If the plugin architecture uses VIs, or classes, or PPL, you will always need to enumerate the plugins not included in the EXE.  The easiest way is to enumerate a folder of files and say each one is a plugin.

Alternatively you could have something in the middle like a text file that says where to find the plugins, or a registry to read that says where they are as an absolute path.  But then you have another place where the fragility of the system could be seen.  In addition to the plugins not being where they should be, your text file could be broken, or missing.  At least with a PPL, or LLB, or Class you have a single file that is seen as the main which references the others.

As much as I resist classes complicating things, this is a prime example of where they should be used.  I don't want to change your design if it is too late, but you should  at least take a look at the Hardware Abstraction Layer.

http://www.ni.com/example/31307/en/

https://decibel.ni.com/content/docs/DOC-15014