10-22-2019 03:48 AM
I have a library that shows two PPL dependencies when opened in a project.
I then open one of the VIs in that library which loads it into memory.
A new dependency is added...
I close the VI and the dependency disappears.
I have cleared both the compiled object caches, performed a mass compile on the directory, closed and reopened LabVIEW and created a new project and imported the library, but still the same result.
Does this mean we can't trust the LabVIEW dependency list? Is this a known bug/"feature" of LabVIEW?
10-22-2019 02:19 PM
Not that I know the answer but have you tried...
Right-click >>> Why is this in depenacies?
and
Find all...
Ben
10-22-2019 02:37 PM
I don't think that LabVIEW evaluates the dependencies of PPLs until they are actually loaded. Since you didn't show your block diagram I assume that the VI you are opening calls a subVI in one of the dependent PPLs. The string library is a dependency of the PPL. If you move the PPls into the project itself, not listed as a dependency, then I think you will see the string library in the dependency list.
10-22-2019 02:40 PM
@Mark_Yedinak wrote:
I don't think that LabVIEW evaluates the dependencies of PPLs until they are actually loaded. Since you didn't show your block diagram I assume that the VI you are opening calls a subVI in one of the dependent PPLs. The string library is a dependency of the PPL. If you move the PPls into the project itself, not listed as a dependency, then I think you will see the string library in the dependency list.
That would be a valid answer to a "why" question (which are the hardest questions to answer).
Ben
10-22-2019 03:03 PM - edited 10-22-2019 03:10 PM
Thanks for the input both
The block diagram of the VI in question:
As you can see, it called all 3x String.lvlibp functions directly. The other files in the Minimal error.lvlib used the FQN version of the PPL. AGDSystems.String.lvlibp is basically the same as String.lvlibp, just built with the updated name.
It wasn't until I'd built the Minimal error library into a PPL and used it in multiple places/projects that I realised it still had a dependency on the older PPL (hence my frustration).
For a larger project/library where multiple VIs are not currently in memory, this could (and probably has, come to think of it) cause some confusion.
For this library I would have expected it to load all the VIs into memory, obviously I'm unsure of the decision process behind LabVIEW deciding to load some VIs and not others 🙂
Probably right about the PPL loading. I've lost trust in the dependencies list now. I suppose ideally all VIs should be manually loaded into memory before assuming it's correct.
10-22-2019 03:31 PM
A co-worker of mine is actually building a tool that will determine the complete hierarchy of dependencies as well as the order that things need to be built. In our environment we have over 170 PPLs with a hierarchy about 10 layers deep. Needless to say building the entire library chain can be quite a task to manage. We currently use MGI's Solution Explorer and Jenkins to build things in the correct order, however this doesn't necessarily build only the portions that need to be rebuilt when a change occurs. The safest approach currently is to build everything if we have made quite a few changes. Hence the desire to build the tool which will manage the dependencies and build order for us. We are hoping to release this publicly once it is complete.