I have 2 seperate applications that are managed by 2 seperate lvproj (project) files. more may follow. They each are in their own subversion repositories. What's the best way to set things up so that I can 1) share some of vi's that are common to both applocations, and continue to add to and modify vi's in the shared whatever (project, library,???).

Please advise before I step off into LabVIEW crosslinking hell!!

I'm using LabVIEW 8.5 (soon going to 8.6) on windows xp pro

Thanks

This post has been edited by HChandler: Aug 28 2008, 10:34 PM

Create a single project that has the common VIs, and only the common VIs, in it. Those should be off in an isolated subdirectory. Whenever you edit those VIs and want to publish those changes for everyone else to use, use Build>>Source Distribution and export your VIs to the common directory that all other projects share.

Use VIPM. 2 projects might grow to more projects, and maybe your internal developer base will grow too - I suggest you spend the time setting it up right so it's not painful down the track...

According to NI's marketing, if you want to share code between projects, the best way is to use library (*.lvlib) files. At least that was the initial reason for libraries. On the other hand, NI changes their message every few months so it's possible that libraries are a thing of the past already.

Of course an even better way is to create VIPM packages.

The problem with that is that you will be tempted to make changes in the "common directory" since those VIs will be loaded and editable. One solution would be to make the whole folder read-only, so LabVIEW would not be able to store your foolish edits. That is safe, but will probably get old in a hurry.

Any way you go, you will probably want a separate SVN repository for your reuse library.

If you use "SVN externals" (more details in the svn docs), you can include the reuse library within each of your other projects. With the SVN external, local changes to the reuse library will be checked into the reuse repository along with your normal checkin. Once checked in, the improvements will be available to your other project(s) whenever you proceed to update them. Some SVN users think this is evil, but you will find it quite handy.

Whenever you release your software, you can change the svn:external to point to a specific revision of the reuse library, so your release is protected from future evil changes in the library. Whenever you change the library, you risk breaking the other projects, but unless you are talking about released code, you should just keep fixing it and making the interfaces as clean and encapsulated as possible and the bugs will be minimized over time.

To avoid the cross-linking, all you have to do is make sure that none of your reuse VIs access any of the project-specific VIs. Part of this is just good design, but in case you slip up, I would write a tool that inspects all loaded VIs and makes sure that no VIs in your reuse folder call any subvis outside that folder. It would be great if LabVIEW had better support for this, but you may be able to adapt Ton's Project Scanner (http://forums.lavag.org/Project-Scanner-t11635.html) to get this working, or else trick him into adding it as a feature.

You will also want to check out the VI Package Manager http://www.jkisoft.com/vipm, which was designed to solve many of these problems. [others beat me to this before I could finish my post]

AQ's advice about splitting out your reusable VIs into a separate project is a good one -- when you create something that's reusable, you need to start treating it like a separate software product (with versions, customers, etc.).

Putting your reuse VIs into an lvlib can certainly help avoid cross-linking, but it won't help you manage your reuse library's software life cycle or aid in managing projects that use the reuse library.

As others have mentioned, VIPM exists to help you take control of your reusable VIs. And, you asked the question at the right time -- you haven't yet lost control. I recommend that you download VIPM and try to make a VI Package, by following our Package Building Guide.

Oh, another great benefit of using VI Packages for your reusable VIs, is that you can add them to the LabVIEW palettes (and customize the layout).

Thanks,

-Jim

Thanks for all of the great advice.

Anyway. I'm not completely starting from scratch. Most of the "reuse" vi's are contained in either folders, or lvlibs in application #1. There are also some vi's that would be good to include in the "reuse" library(project?) in application #2.

So, how do i
1. safely extract the vi's from their current projects, folders and svn repositories
2. merge them into the new reuse project, directories, and svn repositories
3. and finally. How do I get things relinked in one swell foop. That is without spending hours resolving dependencies, and eliminating conflicts.

Thanks for all of the help.

What follows is a rant, so stop reading now if you wish

I can't help feeling that NI has over sold its "professional" development system. After spending 4 grand, the thought of spending an additional $1K...

Having formerly worked on integrated java/c++/etc projects using cvs and other free tools, the fact that this is such a huge and painful issue seems to be a huge oversight no NI's part.

I guess that's what happens when everyone's drinking the same cool aid.

This post has been edited by HChandler: Aug 29 2008, 04:05 PM

If you have a reuse folder, I would just export it from svn, move it somewhere else on your HD, make a new SVN repo, and then try to load your old project. You may need to remove your reuse Vis from the project first, not sure. Be sure that the reuse VIs have been remove from the former hard drive location where they had been seen by your lvproj vis.

Then I would load the project, and then make a new VI within the project, and drop as many of the reuse libs you can on that new VIs diagram. Then I would load your existing VIs and hopefully they will safely relink to the new location. The main thing is you have to make sure the old ones can't be found and that the new ones are in memory in your lvproj's application instance (loaded by some VI included in your project).

Good luck





Well it's true that "professional developers" have not been NI's bread and butter to date. Those free tools don't have some of the great out-of-the-box functionality with hardware that NI has, and NI has great tech support, which you pay for. A seat of LabVIEW costs a lot less than other kinds of software which make 'real' engineers productive, like ProE or Solidworks. I think that compared to the cost of labor for an engineer, the cost of the toolset (i.e LabVIEW and MS Office and a PC) to make that labor have value is relatively small; it's just a few percent of the total cost.

But you're right about the kool-aid.

Jason

Oh crap.

I fell in the abyss.

I'm now in the need of some serious conflict resolution therapy.

I know it does no good but it feels so good to say --- I HATE YOU NI!!!!

If you need a break from your relinking troubles, check out the video we just posted of our NIWeek 2008 presentation, Effective LabVIEW Code Reuse Strategies and Tools.

Cheers,

-Jim

OK - I'll play the devil's advocate: If I understand what you're saying, your hatred toward NI isn't justified - you chose the design pattern, and now you have to sleep in it

OK, I'm back.

Mr. CRELF has thrown out the raw meat, so,...
Warning:
The crankiness that follows may be due the fact that I've had my labor day weekend spoilt by Hurricane Gustav and I really don't feel like working today.

Well. the part I'm mad at them for is not giving the developer more control of what gets linked to what.

Admittedly, I'm a babe in the woods when it comes to LabVIEW development, and I should have laid a better foundation. Still, I would much rather deal with a Makefile than the interminable dialogs and "stuff being done because it was programmed that way by someone who's assumed (and you know what that means) that everyone is on the same page with regard to programming style.

Or should I say styles. Like everything in labview, I've got a million ways to screw myself over. I've got the project, llbs, lvibs, all of that OO stuff, project folders (auto populating and virtual). I have very little determinism. Too much gets done for you, and in ways that you might not want to have happen.

How about a simple two step compile and link process with text based text compile and link lists. I know, the LabVIEW people like to do everything with pictograms, but sometimes it's just not worth it to continue to follow a tortured metaphor for EVERYTHING!

Why can't I turn off automatic linking! Why can't I explicitly (and exclusively) specify what to link to and what to compile?

Why do I have to chase my tail around trying to resolve conflicts????

It's like nailing jello to the wall!