LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

copy a class from dependencies to project

Solved!
Go to solution

I used some progress bar VIs that I found via VIPM.  I want to open and debug my source code on other PCs that don't have the same VIPM components installed.  I want to achieve this by having a copy of the required VIs inside my project folder structure.  However, because the progress bar VIs are inside a class, I don't know how to "save as" to break the link with dependencies.

My goal is to retain the progress bars, but not have them as a project dependency.

class.jpg

Under dependencies I can see ProgressBar_WireFlow.lvclass & ProgressBar_Win_WireFlow.lvclass.

In hierarchy view I see this:

hierarchy.jpg

How do I edit my project such that when I move to another PC, it doesn't fall over asking for the progress bar VIs ?

0 Kudos
Message 1 of 9
(4,307 Views)

If your dependencies are relatively narrow (i.e. just one class) then open the class and Save As to make a copy inside your project directory.

Then, go to the calling VI (looks like "Update Pro-gress" icon)  and change the VIs that it calls so that they don't call the vi.lib / instr.lib copy anymore, and instead call the new copy.

Now, you should have a dependency that in the Files View of the project shows them inside your directory. Optionally (and it's probably a good plan) drag them from dependencies into the project.

 

Note that of course any changes you make won't be reflected in the instrument/VI library copy.


GCentral
0 Kudos
Message 2 of 9
(4,306 Views)

It seems like you are trying to get around the point of a Package Manager.  If you move to another PC, you just need to make sure that PC also has that package installed.  You can do this with a vipc (VI Package Configuration) file which can contain all of the packages you need for that 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 9
(4,280 Views)

It seems like this question is explicitly about avoiding taking the same package to another deployed system.

 

Further, VIPCs aren't available with the free VIPM tool and require a pro licence (although that isn't particularly expensive I suppose, but I don't have it, for example).

 

As a side point, if it goal is to take only part of a package, it might be important to check the licencing terms of that package...


GCentral
0 Kudos
Message 4 of 9
(4,269 Views)

@crossrulz wrote:

It seems like you are trying to get around the point of a Package Manager.  If you move to another PC, you just need to make sure that PC also has that package installed.  You can do this with a vipc (VI Package Configuration) file which can contain all of the packages you need for that project.


I need to get around the Package Manager.  I have a whole factory full of identical manufacturing machines, occasionally I will have access to a machine to debug source code on the hardware.  The extra work of maintaining Package Manager on every machine is a huge overhead I don't want.

At present, regardless of which machine I'm on, I right-click the desktop to checkout the whole project from SVN, I don't want to lose this capability.

0 Kudos
Message 5 of 9
(4,257 Views)

If I save the 2 progress bar Classes to Project, then right-click every progess bar VI and replace with the same from within the Project, I end up with a conflict between the library copy and the project copy.

 

Dependencies View:

dependenciesView.jpg

 

Project View:

projectView.jpg

 

Resolve Conflict View:

resolveConflictView.jpg

 

How do I get the Project to completely forget about the Library copy, and resolve the conflict?  This technique is usually okay when classes are not involved.  What is required?

0 Kudos
Message 6 of 9
(4,253 Views)

I'm searching for places where the project may be pointing to the old unwanted .llb path.

After I've replaced the VIs, the project wants to revert to the "Already Loaded" .llb path.

 

How do I stop the .llb path loading ?

 

0 Kudos
Message 7 of 9
(4,250 Views)
Solution
Accepted by topic author bmann2000

I suspect there is a better way, but if you already tried restarting LabVIEW, my crude suggestion would be to delete the "old" copy and then restart LabVIEW. Then, either it will relink or it will give missing VIs, which you can take the new one for.

 

Edit: For clarity, by "delete" I mean, from the hard drive. You can restore it later if required.


GCentral
0 Kudos
Message 8 of 9
(4,247 Views)

I renamed the folder containing the library VIs and restarted LabVIEW.  This made LabVIEW relink to the new project path VIs.

It was messy, but I got there in the end.

0 Kudos
Message 9 of 9
(4,243 Views)