LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Packed library file paths

Solved!
Go to solution

I have been using packed project libraries for a while on a project with no problems.

 

From an executable I run a VI in this packed lib dynamically with a relative path. This has been working perfectly.

 

All of a sudden, it has stopped working because the 'path' in the project lib has the entire folder tree replicated. I don't know what has changed to make this happen. I have also reverted to a much older version of the project but get the same symptoms implying something has changed in the LabVIEW IDE.

 

For example, before if my packed lib was stored in

A:\project\LabVIEW\builds\Client UI Packed Lib.lvlibp

 

the tablet UI Loaders path would be in

A:\project\LabVIEW\builds\Client UI Packed Lib.lvlibp\Tablet UI Loader.vi

 

The behaviour I am seeing now, which is also shown in the screenshot, is that the tablet UI loader has the following path

A:\project\LabVIEW\builds\Client UI Packed Lib.lvlibp\A\project\LabVIEW\builds\Client UI Packed Lib.lvlibp\Tablet UI Loader.vi

 

As you can see the entire folder tree is replicated.

 

Anyone have any suggestions as to what setting may have changed for this to be happening now?

 

Niatross_0-1644253796077.png

 

0 Kudos
Message 1 of 5
(237 Views)

It looks like somebody did "Something Wrong (tm)" in the SCC repository. 

 

I recommend retraining for the individual using negative reinforcement

 

 

JB_0-1644256228959.png

 


"Should be" isn't "Is" -Jay
0 Kudos
Message 2 of 5
(228 Views)
Solution
Accepted by topic author Niatross

It looks to me that the PPL was built with a VI being called from another drive.  I would guess you got a cross-contamination with another project.


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
0 Kudos
Message 3 of 5
(210 Views)

Correct. After tidying up the project dependencies I found one VI which was being called from another projects directory.

 

Fixing that solved my problem.

 

What I am a little confused about is why LabVIEW was looking there in the first place. Also I am confused as to why reverting to an old version didn't solve this issue, especially seeing as the revision I reverted to was before the other project was even started

0 Kudos
Message 4 of 5
(169 Views)

@Niatross wrote:

Correct. After tidying up the project dependencies I found one VI which was being called from another projects directory.

 

Fixing that solved my problem.

 

What I am a little confused about is why LabVIEW was looking there in the first place. Also I am confused as to why reverting to an old version didn't solve this issue, especially seeing as the revision I reverted to was before the other project was even started


Vis in memory is a high priority default search path.  This makes "Flossing" your lvproj a bit more painful when some developer does "Something Wrong (tm)" in SCC.  

 

The standard slap of the female canine variety is a useful negative reinforcement training tool.


"Should be" isn't "Is" -Jay
0 Kudos
Message 5 of 5
(159 Views)