LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

PPLs Seemingly Very Particular About Where They're Built

For reference, I am using LabVIEW 2017 SP1 on a Windows 10 machine.

 

I recently inherited a large LabVIEW project which uses quite a few PPLS (approx. 20). Many of these PPLs have dependencies on others. From what I can tell it is never a two-way street (i.e. where two PPLs both call VIs from each other), but there are hierarchal relationships between them. They are ultimately all used in this top-level project.

 

I ran into an interesting issue with this and was hoping the community might have more info/guidance - keep in mind I've never used PPLs before but have been doing quite a bit of reading on them. I do seem to have solved the issue and wanted to share what info I have as well.

 

Initially I was building these PPLs in various individual locations, then moving them to a common folder. This common folder was then included in my top-level project for use. When building say, PPL B with a dependency on PPL A, I would reference the copy of PPL A that was in this common folder. Thus all builds that required any PPLs would use this common location. However this seemed to cause a couple different and odd issues:

 

  1. Some (seemingly random) VIs within the PPLs could not be found in the top-level project. I would be able to see the PPL in the project and the VIs in question, but they would show up under dependencies as having been deleted or moved on disk. I tried replacing these dependencies with the files explicitly, but they would simply reappear under dependencies. I'd be able to build an exe, but when running it would not be able to find these VIs.

 

  1. Issues generating an exe preview. I'd be able to build an exe no problem, but when I'd try to generate a preview I'd get error 7. This is similar to issue 1 - it would be unable to find a particular VI within one of the PPLs. The interesting thing with this issue is that if I closed LabVIEW entirely and reopened the project, I'd be able to successfully generate an exe preview exactly once before the issue would resume. All without making any actual changes within the project.

Ultimately I was able to solve this by building the PPLs directly into the common folder location. Why is this necessary though? I would think that if they ultimately end up in the same location with their dependencies, they'd be able to find everything...but clearly this wasn't the case. It also seems very strange that it's only a handful of seemingly random files that had problems.

 

If anyone has any insight on this I would be very interested. Happy to provide more info if needed as well.

0 Kudos
Message 1 of 7
(2,430 Views)

@TBogardus wrote:

Ultimately I was able to solve this by building the PPLs directly into the common folder location. Why is this necessary though?


I had to do exactly the same thing.  The relative paths from the newly built PPL to any other PPLs is depends on must remain consistent to use it.  In order words, you can't just randomly move your PPLs unless you are moving everything.


GCentral
There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines
"Not that we are sufficient in ourselves to claim anything as coming from us, but our sufficiency is from God" - 2 Corinthians 3:5
Message 2 of 7
(2,411 Views)

Thanks for the response - that much does make sense, and so be it - now I know. What's still odd is why only a handful of files were complaining. There were far more that had the same condition of being a dependency that were found just fine.

 

I'm also still pretty perplexed at the issue generating an exe preview. Mainly hoping for information on the "why" of these two points.

0 Kudos
Message 3 of 7
(2,408 Views)

@crossrulz wrote:

@TBogardus wrote:

Ultimately I was able to solve this by building the PPLs directly into the common folder location. Why is this necessary though?


I had to do exactly the same thing.  The relative paths from the newly built PPL to any other PPLs is depends on must remain consistent to use it.  In order words, you can't just randomly move your PPLs unless you are moving everything.


That is not absolutely true. You can use different folder locations for your development environment and the built exe. The important thing to preserve is the folder depth relative to the PPLs. It gets pretty confusing and a bit of a pain to manage but once you get it figured out it is workable.

 

What I would love though is the ability to provide a base path or search path for PPLs so they could be easily moved, even in a built application.



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
Message 4 of 7
(2,383 Views)

I'm facing similar issue in LabVIEW 2023, please see the screenshot below. But it is referenced some default VIs from the LabVIEW Vi.lib

 

VipinFR_0-1723028822717.png

Can you help me to resolve this issue, I followed your steps mentioned in this topic, but still, I could not solve this issue.

0 Kudos
Message 5 of 7
(223 Views)

I reported a similar bug to NI awhile back. (Preview complains about a namespace issue in PPL in LabVIEW 2023 but not earlier versions)  The bug number is 2572987 in case yours is the same issue. I don't know the status of what has happened since though.

0 Kudos
Message 6 of 7
(202 Views)

Hi,

 

Thanks for your response.

 

I'm also encountering the same issue. There was no Preview error in the LV2020 version, but I found this issue after upgrading to LV2023.

I am able to build all the PPL and EXE, but it shows a preview error.

 

When I try to build the final package, it throws an error. I believe NI needs to look into this issue soon and release a patch to fix it.

 

Vipin

0 Kudos
Message 7 of 7
(182 Views)