LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Packed library contains folder structure

Solved!
Go to solution

I build a LVLIBP, where I want to have only the containing VI's. As I try to specify module in TestStand, I see that the LVLIBP contains the entire Folder structure of the path of the library. How can I build it without the Folder structure?

folder struct.PNG

0 Kudos
Message 1 of 7
(3,663 Views)
Solution
Accepted by topic author Madottati

Depending of file types, a relative path to the sources started from the lvlib file is included in the PPL.

As your screenshot does not show the complete content of the PPL, i can only guess about the setup.

 

It seems to me that the lvlib file is not part of the _Git\NI_Digital_IO\Public functions folder on your disk. Where is it located (relative to this folder) when building the PPL?

Are you using auto-populated folders in that project?

Norbert
----------------------------------------------------------------------------------------------------
CEO: What exactly is stopping us from doing this?
Expert: Geometry
Marketing Manager: Just ignore it.
Message 2 of 7
(3,655 Views)

Hi Norbert,

 

I have moved the PublicFunctions.lvlib into the Folder PublicFunctions, now it Looks better. Originally the lvlib was located outside the PublicFunctions Folder.

without folder struct.PNG

 

So the solution works, but what is your concern about auto-populating Folders?

0 Kudos
Message 3 of 7
(3,646 Views)

I personally do not like auto-populating folders. For most use-cases, that is just a personal reference.

However, in specific cases, auto-populating folders can induce issues. One example where NI does recommend to NOT use auto-populating folders is in complex architectures with a lot of LV OOP (e.g. Actor Framework based applications).

My personal experience is that auto-populating folder can lead to strange results when creating applications and source distributions with the LV AppBuilder.

Norbert
----------------------------------------------------------------------------------------------------
CEO: What exactly is stopping us from doing this?
Expert: Geometry
Marketing Manager: Just ignore it.
Message 4 of 7
(3,642 Views)

It has nothing to do with auto-populating folders. The structure depicts somehow the relation of the lvlib and its VIs before building. I have a similar problem. I also realized that it can be totally messed up if you have dll referenced in dependencies.

 

I would be happy if someone would point me to a source that describes how this structure is created.

Michał Bieńkowski
CLA, CTA

Someone devote his time to help solve your problem? Appreciate it and give kudos. Problem solved? Accept as a solution so that others can find it faster in the future.
Make a contribution to the development of TestStand - vote on TestStand Idea Exchange.
0 Kudos
Message 5 of 7
(1,810 Views)

I did some research. Folders visible in TS when selecting a VI from a PPL indicates where the VI is in relation to the library file. Let's say we have the following structure:

 

C:\TESTS
├───A
│   ├───B
│   │   └───C
│   │       │   B.vi
│   │       │   MyLib.lvlib
│   │       │   MyProject.lvproj
│   │       │
│   │       └───Sources
│   │               A.vi
│   │
│   └───D
│           C.vi
│
└───Build
        MyLib.lvlibp

 

And MyLib.lvlib in the project looks like this:

 

└───MyLib.lvlib
        A.vi
        B.vi
        C.vi

 

When we build MyLib.lvlibp and open it we will see the following paths in VI properties:

 

C:\Tests\Build\MyLib.lvlibp\B\C\Sources\A.vi
C:\Tests\Build\MyLib.lvlibp\B\C\B.vi
C:\Tests\Build\MyLib.lvlibp\D\C.vi

 

 

Those additional folders after MyLib.lvlibp will be visible in TS in the "Select a VI from LabVIEW Packed Project Library" window.

 

I don't know how to explain it in proper terms but it looks like the additional folders are created to somehow depict the relation between MyLib.lvlib and the C.vi (as you can see C.vi is on a "shallower level" and in a different "branch" than MyLib.lvlib).

 

If I now remove C.vi from MyLib.lvlib, the additional folders will disappear. Inside of the PPL I will have:

 

C:\Tests\Build\MyLib.lvlibp\Sources\A.vi
C:\Tests\Build\MyLib.lvlibp\B.vi

 

 

So if we mess up our files structure in the project, we will also have a mess inside of PPL. I think it is best to keep VIs and the library on the same level or to keep VIs deeper than the library.

 

EDIT:

My previous comment regarding DLL was wrong.

Michał Bieńkowski
CLA, CTA

Someone devote his time to help solve your problem? Appreciate it and give kudos. Problem solved? Accept as a solution so that others can find it faster in the future.
Make a contribution to the development of TestStand - vote on TestStand Idea Exchange.
0 Kudos
Message 6 of 7
(1,793 Views)

@bienieck wrote:

I don't know how to explain it in proper terms but it looks like the additional folders are created to somehow depict the relation between MyLib.lvlib and the C.vi (as you can see C.vi is on a "shallower level" and in a different "branch" than MyLib.lvlib).


The directory structure inside of a PPL is the same as an executable.  They both will use the lowest common folder as the "base" folder in order to retain relative paths for all VIs to be included.


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 7 of 7
(1,774 Views)