04-24-2020 04:25 AM
Hello,
we are a team of 3-4 LabVIEW-developers working on different projects. Over the time we created a decent amount of API "palettes" that we use to communicate with all kinds of hardware via all kinds of interfaces.
Right now we place those locally in the user.lib folder under National Instruments/LabVIEW 2019 and keep a copy on a shared folder. Every time one of us changes or adds a new palette, he updates the copy on the shared folder and we all have to update our user.lib accordantly. This works for just a few libraries, but gets more and more difficult now.
So my question is: what is the best way to synchronise those libraries or "palettes" (still not sure what's the correct term)?
I thought about adding the shared copy directly to the palette sets, but I guess that will cause troubles as soon as more then one of us tries to access those VIs.
Another way might be to distribute these APIs as seperate or even a bundled installer that the team needs to execute every time we updated the APIs.
What is your suggestion?
Thanks very much!
Sylvan
04-24-2020 05:25 AM - edited 04-24-2020 05:28 AM
Hi sylvanus,
this is where SCC (Source Code Control) comes into play!
Use any tool you want (like SVN, GIT, …) - but use one of those tools!
Now all you need to do is to setup a repository where all members of your team check out/commit code changes. (Search this forum for "SCC" or "SVN" to find a lot of threads on this very topic.)
@sylvanus wrote:
Right now we place those locally in the user.lib folder under National Instruments/LabVIEW 2019 and keep a copy on a shared folder.
I prefer not to place any "own" code in the user.lib, but use a subfolder in my "global" projects folder - as written just two days ago…
04-24-2020 05:53 AM
As far as distribution, you should be using a package manager such as VIPM. Then when you have an update, you can just "install" the package. But you would also have older packages that you could have installed depending on the project.
04-24-2020 07:27 AM
I second the motion on VIPM, especially if these API's are being updated with some regularity. VIPM makes it pretty straightforward to select a specific older *version* of a package to install in case some of the updates aren't truly back-compatible.
-Kevin P
04-24-2020 09:12 AM
Thanks to all the replies so far, very helpful!
I will definitely dig into SCC and figure out what repository tool to use.
@crossrulz: I didn't know about the possibilities to use the VI package manager for non-official internal packages. This sounds very promising! Is there any good instruction on how to correctly use it?
Another question that's stuck in my head: Is it correct to use a library for APIs in palett sets? Because, what I noticed, when contained in a library, LabVIEW doesn't give me the option "Replace --> <Owning> Palette".
See:
This is not too much of a deal, I'm just wondering if I'm missing something here.
Thanks again!
Sylvan
04-25-2020 10:18 AM
@sylvanus wrote:
@crossrulz: I didn't know about the possibilities to use the VI package manager for non-official internal packages. This sounds very promising! Is there any good instruction on how to correctly use it?
Sylvan,
VIPM has been around for a decade or so. It is designed for "non-official internal packages". It is the "tool" behind the LabVIEW Tools Network, created and maintained by JKI. It is not the same as the (deliberately? confusingly?) named NI Package Manager, which is the newly-released tool that NI uses to install LabVIEW and its "packages" (formerly called Modules, Toolkits, and Drivers). I think it might have the ability to manage User Libraries, but VIPM works, has worked, and (for the foreseeable future) should continue to work.
Bob Schor
04-26-2020 08:50 PM - edited 04-26-2020 08:52 PM
I can personally attest to VIPM magic. It works most awesomely. I keep my reuse librarie source code in the place where my other LV projects go, and I build a distribution installer with VIPM. It let's you build complicated palettes very easily, and appear in the right-click menu. the pro version lets the palettes appear in the "replace with..." menu also.
04-27-2020 03:11 AM
I agree with what's been said. VIPM or NIPM, developed in a SCC'd project. (wow that's a lot of abbreviations in one sentence) 🙂