PPL Loading Issues

[_carl]

My PPL doesn't load when I add it to a project by itself.  If I right-click and attempt to load, it gives me the pop up below:

However, if I first add its PPL dependencies (which are PPLs in vi.lib deployed through VIPM VIPs), and then add my PPL to the project, it loads just fine:

But if I open and close the project above, it fails to load my PPL properly unless I right-click on it and Load.

Any ideas as to what might be going on here?

More details that might be relevant:

- The source code for the top-level PPL relies on the dependency PPLs already being deployed to vi.lib. The dependency list in the project I build from is clean.

- Nothing appears to be broken in the source code before I create the PPL.

- I'm building the top-level PPL directly in a sub-folder in vi.lib, and I'm excluding dependent packed libraries, so it's just a single file that's being created on build.

- One of the dependent PPLs is dependent on another of the dependent PPLs. So the dependency tree looks something like shown below. I do have to wonder if the second level of dependencies is a factor, as I did experience similar issue with a previous experiment once I had two levels of PPLs.

Many thanks, and any suggestions would be much appreciated!

[_carl]

An assumption I've been making is that if a top-level PPL references a PPL in vi.lib, then I don't need to copy the dependent PPL to the folder that the top-level PPL is created in. Is this a valid assumption?

[ShockHouse]

The deepness of the PPLs is not the issue. We have a framework that is way deeper than 2 and it works fine.

My guess is the issue is related to PPLs inside of vi.lib. They do not play nicely from my experience (Having PPLs in vi.lib, user.lib, or instr.lib). And LabVIEW does not properly load them when dependent (as evidenced in your example). Is there anyway you can move those to some common location instead, and then rebuild your top level PPL using the new location instead of vi.lib. Then it should load fine. The key to using PPLs effectively is just to have a build/install location that does not change and is the same on everyones computer (and is not vi.lib, instr.lib or user.lib).

[Kyle97330]

Darren Nattinger, a long-time NI employee and LabVIEW expert, posted this a while back:

Ludicrous Ways to Fix Broken LabVIEW Code

In the video is a fair amount about PPLs, in which he essentially states:

1. If you can avoid it, don't use PPLs.

2. If you have to use PPLs, put them all in the same folder every time ("C:\PPLs" or similar).

That said, have you built your PPLs with debugging enabled?  Might give you a better idea of what's going on and where it thinks its dependencies ought to be.

[_carl]

I fear that you may be correct... and that in turn has concerning implications in my scenario. I'd like to be able to package up my re-use libraries as PPLs in VIPM VIPs so that I can easily re-use them across projects, and allow those projects to contain PPLs.  It seems like this restriction would prevent me from doing exactly that (and would be all ears if anyone had any suggestions for workarounds).

If what you're describing is correct, it sounds like a LabVIEW bug to me -- curious if there are any fixes for this in the pipeline... (I'm on 23Q1, but had similar results with an experiment I ran on 24Q1.)

[_carl]

---

@Kyle97330 wrote:

Darren Nattinger, a long-time NI employee and LabVIEW expert, posted this a while back:

Ludicrous Ways to Fix Broken LabVIEW Code

---

Unfortunately, I'm in a situation where I need to break most of Darren's rules, specifically:

I require PPLs for a solid plug-in based architecture.  And there's really no reasonable way my software can scale to do what I need it to do without malleable VIs (short of scripting), classes (short an entirely unusable architecture, millions of case statements, and/or years of scripting), and typedefs (for sanity).

I've been able to work around most class/VIM related issues to date -- it's just this last hurdle of PPLs, and my issue here doesn't even seem to be tied to VIMs or classes, but I could be very wrong about that...

[ShockHouse · Accepted solution]

PPLs themselves are not an issue. Classes in PPLs are not an issue. We have 100's of PPLs that we reuse across 100's of applications without issue (including ones with multiple classes because of Actor Framework without issue). BUT XNodes and VIMs can cause issues in PPLs though, we have seen that first hand.The key to PPLs is to avoid vi.lib, user.lib and instead either keep them in the same location always, or understand the relativity of PPL paths and keep them always in the same relative location of each other. What that means is you build PPL B, and it relies on A. Where ever A is on disk, when you build B, it should stay the same relatively. If another user wants to use B and A, they should keep it the same.

We do exactly what you are after, re-use libraries as PPLs. But we do not use VIPM, we use NI Package Manager. Since you want your PPLs to build, and be installed to the same place on every computer, NI Package Manager is the perfect step for that. And you can build those packages straight from LabVIEW build specs just like your PPL. Then you have a *.nipkg that anyone can run and install the PPL on their own machine. You can have multiple of those packages to install individually PPLs, or a single one that installs many, up to you.

What you are after is possible with PPLs. We do it all the time. The great benefit of it is, PPLs are backwards compatible so we build our reuse in LabVIEW 2019, and have customers all the way up to 2024 using the exact same PPLs and NIPM Packages. That's the other benefit you miss by installing PPLs to vi.lib. Multiple LabVIEW version support. 

[_carl]

Alright, so...I updated my VIPM packages to deploy to "C:\PPLs" instead of vi.lib, and it appears that I'm past this hurdle!

It's unfortunate that vi.lib doesn't work as expected -- and that the errors coming out of LabVIEW don't really provide much guidance. But I'm happy to be back on track, so thank you guys for the help!