06-29-2018 03:59 AM
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.
Under dependencies I can see ProgressBar_WireFlow.lvclass & ProgressBar_Win_WireFlow.lvclass.
In hierarchy view I see this:
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 ?
Solved! Go to Solution.
06-29-2018 04:10 AM
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.
06-29-2018 07:52 AM
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.
06-30-2018 03:04 AM
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...
07-02-2018 03:58 AM
@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.
07-02-2018 04:26 AM
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:
Project View:
Resolve Conflict View:
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?
07-02-2018 04:59 AM
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 ?
07-02-2018 05:12 AM - edited 07-02-2018 05:12 AM
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.
07-02-2018 05:27 AM
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.