LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Why are true project dependencies not shown?

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.

Does anything work correctly in LabVIEW?...Does anything work correctly in LabVIEW?...

 

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?



Using LV2018 32 bit

Highly recommended open source screen capture software (useful for bug reports).

https://getsharex.com/
0 Kudos
Message 1 of 6
(2,569 Views)

Not that I know the answer but have you tried...

 

Right-click >>> Why is this in depenacies?

 

and

 

Find all...

 

Ben

Retired Senior Automation Systems Architect with Data Science Automation LabVIEW Champion Knight of NI and Prepper LinkedIn Profile YouTube Channel
0 Kudos
Message 2 of 6
(2,486 Views)

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.



Mark Yedinak
Certified LabVIEW Architect
LabVIEW Champion

"Does anyone know where the love of God goes when the waves turn the minutes to hours?"
Wreck of the Edmund Fitzgerald - Gordon Lightfoot
0 Kudos
Message 3 of 6
(2,477 Views)

@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

Retired Senior Automation Systems Architect with Data Science Automation LabVIEW Champion Knight of NI and Prepper LinkedIn Profile YouTube Channel
0 Kudos
Message 4 of 6
(2,474 Views)

Thanks for the input both

 

The block diagram of the VI in question:

xDu9AOCPyl.png

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.



Using LV2018 32 bit

Highly recommended open source screen capture software (useful for bug reports).

https://getsharex.com/
0 Kudos
Message 5 of 6
(2,465 Views)

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.



Mark Yedinak
Certified LabVIEW Architect
LabVIEW Champion

"Does anyone know where the love of God goes when the waves turn the minutes to hours?"
Wreck of the Edmund Fitzgerald - Gordon Lightfoot
0 Kudos
Message 6 of 6
(2,456 Views)