Labview packed library internal paths problem

[mperss]

Hello,

I ran into a strange issue today on something that has worked before. I am using labview 2014 with teststand 2014.

I have a project where i have a build specification for a packed project library (.lvlibp), i then use this library in TestStand. 

I have my project in source control and, for it's located for example on my computer at: C:\repository\project\

The project contains multiple nested lvlib's, with one top lvlib that is used as top lib for the packed library.

If my packed library is called PackedLib.lvlibp and the destination is C:\builds\PackedLib\PackedLib.lvlibp

I get the following path when trying to call the vi randomvi.vi(which is located in the root of the lvlib) in the packed lib from TestStand: C:\builds\PackedLib\PackedLib.lvlibp\repository\project\randomvi.vi

The call to randomvi.vi works but earlier was the path to the .vi only C:\builds\PackedLib\PackedLib.lvlibp\randomvi.vi, the result of this is that all my teststand code that has the old path cannot find the .vi's which makes it really annoying to update all the references, (and what if it would change back with the next compliation then the problem remains!)

I am using only relative paths in the project what I know of and all my files are located on the same drive. After inspecting the .lvlib files with notepad i can see only relative paths.

This issue arose today and I'm puzzled on what I might have done to create this issue. I have tried to start another project(with only dummy files) to see if it related to teststand, but i do not get the same issue, is there something that might have caused this issue and somehow corrupted the project file or is it a intended behaviour?

[VItan]

Have you always been using LabVIEW 2014 or only recently changed over to it?

This sounds like the legacy structure of built items vs. new structure: Legacy structure was all flat, while the newer structure allows the preservation of the original disk hierarchy.

In either case, you should be able to get around it by using the packed library VI's to find what you are looking for programmatically.  For example, I believe that there is a VI for finding the actual path to an item given it's qualified / namespaced name, such that you ask "C:\builds\PackedLib\PackedLib.lvlibp" for "PackedLib.lvlibp:randomvi.vi" and it returns "C:\builds\PakcedLib\PackedLib.lvlibp\repository\project\randomvi.vi".

[mperss]

For this project have I used  2014  all the time(recently updated to 2014 sp1 though) , but i might have added .vi's that have originally been developed in an older version, might this have affected somehow? (i have done such additions lately)

I will look into that, but i'm unsure if it might help me with the path problem in Testand (you actually select one .vi to call, i'm unsure if i can select that path programatically)

[VItan]

---

@mperss wrote:

For this project have I used  2014  all the time(recently updated to 2014 sp1 though) , but i might have added .vi's that have originally been developed in an older version, might this have affected somehow? (i have done such additions lately)

---

Adding other items shouldn't cause any problems.  There should be an option for "Perserve disk hierarchy" for items on the Destinations of the packed library's build specification that you can normally uncheck to force the build to use the legacy, flat structure.  However, I don't know if you can even uncheck it for packed libraries.

---

I will look into that, but i'm unsure if it might help me with the path problem in Testand (you actually select one .vi to call, i'm unsure if i can select that path programatically)

---

How are you calling it in TestStand?  Interactively by the operator specifying a path?

If you can't get the info programmatically in TestStand alone, you may be able to make a VI that uses the packed library VI's to get the info from the packed library (such as exported items' paths) and then presents that, then call this VI in TestStand first.

I know nothing about TestStand...

[tyk007]

TestStand will be able to leverage search directories for the path to the lvlibp file dynamically, but the relative path inside that must be known unfortunately.

CHeck your disk hierarchy of the files for your lvlibp. The disk structure (not virtual folder structure) is how lvlibp's are organised. If you shuffle around files on disk prior to building the lvlibp then internal paths will change.

[mperss]

I see, i have noticed the first and assumed the second. But what is the "base path" for the lvlibp?, i mean if my top folder is located somewhere I assumed that the internal paths was going to be relative to that?

I did go through all my .vi's paths in the project and I did notice that a few of the files that I recently have added was actually not located inside the project directory, I move theese files to be under the project (where it should be in the first place) and voila my paths are back to normal again...

If my top folder was at:

C:\repo\project\topfolder.lvlib

and one of the lvlibs under it contained the vi duplicate.vi with the following path C:\users\user1\desktop\duplicate_vis\duplicate.vi

Then what I noticed was that the internal path for the duplicate.vi in the lvlibp would end up to be C:\builds\build1.lvlibp\users\user1\dekstop\duplicate_vis\duplicate.vi

It kind of makes sense if the packed library should mirror the disc hierarchy, is this intended behaviour?

[mperss]

I dont think you can uncheck the "preserve disk hierarchy" for packed libs what I can see. Most of the code is called by preconfigured custom step types in teststand, so that was my initial problem that all of my "steps" could not find it's intended .vi's

[VItan]

---

mperss wrote:

It kind of makes sense if the packed library should mirror the disc hierarchy, is this intended behaviour?

---

Yes it is, and as you just pointed out, it turns out that it's actually not an option to uncheck the "Preserve disk hierarchy" option for packed libraries.

I still don't actually know anything about TestStand, but I did watch a 4 minute video and read an introduction PDF!

For a test management system like that, I would expect to use a pre-test "environment setup" script, which I could see being a VI like I mentioned where it will programmatically interrogate your lvlibp and then provide relavent environment information to the TestStand environment.  Can you have steps in TestStand call a VI by dynamically provided path (stored in a TestStand environment variable), or must it all be static?

[mperss]

What I have seen is it possible via the TestStand API to dynamically load the code modules, so that might be an option if neccessary. But for simplicity's sake(i'm using something called custom step types which is a bit more static) will I probably be more careful of the paths in my project!

[Madottati]

yes, you can uncheck "preserveHierarchy".

Open the .lvproj file in any text Editor, and search for something like this:

<Property Name="Destination[0].preserveHierarchy" Type="Bool">true</Property>

simply Change "true" to "false". For me it is working. I use LV 2015.

Madottati