LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Best way to share APIs amongst the LV development team

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

0 Kudos
Message 1 of 8
(2,122 Views)

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

Best regards,
GerdW


using LV2016/2019/2021 on Win10/11+cRIO, TestStand2016/2019
Message 2 of 8
(2,101 Views)

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.


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
Message 3 of 8
(2,096 Views)

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

CAUTION! New LabVIEW adopters -- it's too late for me, but you *can* save yourself. The new subscription policy for LabVIEW puts NI's hand in your wallet for the rest of your working life. Are you sure you're *that* dedicated to LabVIEW? (Summary of my reasons in this post, part of a voluminous thread of mostly complaints starting here).
0 Kudos
Message 4 of 8
(2,076 Views)

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:

inLibrary.PNGnotInLibrary.PNG

 

This is not too much of a deal, I'm just wondering if I'm missing something here.

 

 

Thanks again!

 

Sylvan

0 Kudos
Message 5 of 8
(2,056 Views)

@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

0 Kudos
Message 6 of 8
(2,002 Views)

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.

Bill
CLD
(Mid-Level minion.)
My support system ensures that I don't look totally incompetent.
Proud to say that I've progressed beyond knowing just enough to be dangerous. I now know enough to know that I have no clue about anything at all.
Humble author of the CLAD Nugget.
Message 7 of 8
(1,969 Views)

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) 🙂

 

G# - Award winning reference based OOP for LV, for free! - Qestit VIPM GitHub

Qestit Systems
Certified-LabVIEW-Developer
0 Kudos
Message 8 of 8
(1,945 Views)