LabVIEW
Information about CAR #723751
Solved!
Hello Sergio,
From reading the thread you linked, it looks like a class inheritance issue. The child class needs to be inherited from the Parent lvlibp (PPL), not the Parent lvlib (lib). If it is derived from the lib, then LabVIEW will prioritize loading the lib, and not load the PPL anymore, as shown in this screenshot from the thread you linked.
Unfortunately, we cannot see what's inside of "Dependencies" here. I guess Limits.lvlib showed up there, which should never be the case. If so, Right-Click » Why is this in dependencies, and then replace all calls to the lib with calls to the PPL.
And, in general: The linked thread is about PPLs used in a plugin structure. For this, PPLs have to be completely self-contained. That is, all dependencies need to be inside the root PPL, or already be loaded before the PPL is loaded. Here, all needed dependencies need to be either in Parent PPL, or set to "Always included" in the executable build specification.
Apart from that I tried to reproduce the issue here. It works for me as intended. Sergio, do you have code where this is an actual issue? It's easier to troubleshoot existing code than discussing such an issue theoretically with at least a dozen of unknowns.
Hello Sergio,
Sorry for the delayed answer, I needed to find enough time to do some testing.
I'll split this answer in three sections. The first is about I would set up the folder structure for a plugin project. The last one is about the behavior you see. As far as I understand, the behavior should be irrelevant in regards to your goals. PPLs that are used as plugins need to be fully self-contained, therefore dependencies have to be loaded beforehand. Section 2 is about this.
=== Plugin structure ===
I have two goals when creating a plugin structure: Keeping an easy overview over your sources and builds, and keeping the number or PPL copies as low as possible.
I would use a folder structure like this
- \project\_builds\
- \project\main sources\
- \project\plugin parent sources\ (both main and all plugins are inherited from this one)
- \project\plugin1 sources\
- \project\plugin2 sources\
- \project\plugin[...] sources\
What do I then do?
- All Build Specifications point towards the _build folder, not to vi.lib or similar(*). Plugins dependent on other PPLs you made use this folder as source for these PPLs. LabVIEW will find the dependency PPLs here. No "Library could not be loaded" message. (see attached components_ik.zip)
- Check "Exclude dependent packed libraries" and "... shared..." in all plugins.
- Pull all your shared dependencies you want to use in more than one plugin into the main program's project, and set them a "Always Included". This way they are available before the plugins gets loaded (depends on the actual code inside those dependencies).
- For future dependencies that you did not compile into your main program: Compile them into that respective PPL. There are several ways to to, see the following section.
*: I know that there are certain limitations to this. E.g. when compiling your plugins for very different targets, it's sometimes impossible to use PPLs, going for LLBs instead. Different types have different Build Specifications. Some allow "exclude dependencies from user.lib", therefore you sometimes actually want to have some llbs/ppls in there.
=== Loading dependencies ===
In general, dependencies of self-contained PPLs have to be loaded before the PPL itself is loaded. There are several ways to do so:
- Have the main application load it.
- Publish dependency PPLs and a config file with your "new" plugin PPL. The config file lists the dependencies of that PPL. Your main application has code that reads the config file, then loads the dependencies, then loads the plugin PPL itself. (See attached loader.vi).
- Compile the dependency PPLs (not from vi.lib or user.lib) into the plugin PPL. Load this plugin dynamically using the 0x10 option on the Get LV class defaults. This makes LabVIEW load/search for the dependencies. It's slower, but works as well.
=== Loading behavior ===
Using LabVIEW 17.0.1f3 (64-bit) I see the same behavior as you do. I created a project like yours from scratch in LabVIEW 2018 SP1 and did some testing. I think I can confirm your behavior, however I don't know if it is expected or not. I created a PPL2 that depends on PPL1. If PPL1 was (and still is) inside user.lib or vi.lib when PPL2 was compiled, I get the same message like you when trying to open PPL2. However, when I put PPL1 somewhere else, compile PPL2 with that new dependency path, I can open PPL2. I assume this is due to some kind of optimization:
1) Is the dependency PLL "somewhere"? Try to load it. Search for it. If not available, ask the user to point towards it.
2) Is the dependency PPL in user.lib or vi.lib? Don't bother to load it. The programmer will load the dependencies.
I assume this is the reason for the different behavior: "If I put a PPL inside of vi.lib, I know what I am doing. I want to load my PPLs manually, in the correct order." This sounds like a reasonable explanation to me.
Edit: Mixed up attachments, deleted the duplicate ones.
