Setting up reusable vi's without crosslinking woes

[HChandler]

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 LV crosslinking hell!!

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

Thanks

[Aristos Queue]

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.

[crelf]

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...

[Michael Aivaliotis]

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.

[jdunham]

QUOTE (Aristos Queue @ Aug 28 2008, 03:51 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.

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. :headbang:

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. :thumbup:

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]

[Jim Kring]

QUOTE (HChandler @ Aug 28 2008, 03:24 PM)

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 LV crosslinking hell!!

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

Thanks

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

[HChandler]

Thanks for all of the great advice. :worship:

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... :thumbdown:

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.

[jdunham]

QUOTE (HChandler @ Aug 29 2008, 09:04 AM)

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.

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

QUOTE (HChandler @ Aug 29 2008, 09:04 AM)

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... :thumbdown:

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.

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

[HChandler]

Oh crap.

I fell in the abyss. :headbang:

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!!!!

[Jim Kring]

QUOTE (HChandler @ Aug 29 2008, 03:03 PM)

Oh crap.

I fell in the abyss. :headbang:

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, http://jkisoft.com/niweek/2008/effective-labview-code-reuse-strategies-and-tools/' rel='nofollow' target="_blank">Effective LabVIEW Code Reuse Strategies and Tools.

Cheers,

-Jim

[crelf]

QUOTE (HChandler @ Aug 29 2008, 06:03 PM)

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

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

[HChandler]

OK, I'm back.

Mr. CRELF has thrown out the raw meat, so,...

Warning: :headbang:

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 LV 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 LV 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!

QUOTE (crelf @ Aug 30 2008, 09:00 AM)

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

[Yair]

QUOTE (HChandler @ Sep 5 2008, 07:58 PM)

Why can't I turn off automatic linking!

Because a) the code has to be in memory to be compiled, b) it has to be loaded from somewhere and c) you can only have one VI in memory with a given name.

If you turned it off, LabVIEW would not be able to do its edit time compiling which it currently does and would be not be able to perform all kinds of optimizations it currently does. My understanding was the whole concept of libraries in LV 8.x was to avoid the cross linking problem.

QUOTE

Why can't I explicitly (and exclusively) specify what to link to and what to compile?

You sort of can. If you open a VI from disk and then open a hierarchy calling another VI with the same name your first VI will be loaded. Of course, the practicality of that for multiple VIs is limited.

Should NI have a dialog which will allow you to manually resolve cross linking issues across your entire hierarchy? Maybe, I don't know. You should submit a product suggestion in NI's product suggestion center.

Maybe a dialog like that can be written today, but the first option I'm thinking of will not work, becuase LV will not let you open a reference to a VI on disk with the same name as a VI currently in memory. I believe there is a private method for replacing a VI with another in code, but I'm not sure how it would behave. The only solution might be to keep a list and then close the hierarchy, open the VIs in the list and then open the hierarchy again.

QUOTE

It's like nailing jello to the wall!

http://www.myscienceproject.org/j-wall.html' rel='nofollow' target="_blank">I don't see the problem:

[Justin Goeres]

QUOTE (HChandler @ Sep 5 2008, 08:58 AM)

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

You have all the control you need. But like Yair said, the problem stems (mostly) from the fact that LabVIEW can't simultaneously have 2 VIs in memory with the same (qualified) name. This takes some getting used to, but honestly, for the most part you're feeling helpless right now because you don't yet know how to use the tools that are in front of you. Everyone goes through that at some point, with every new language.

QUOTE

Admittedly, I'm a babe in the woods when it comes to

LV

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.

And I would much rather deal with LabVIEW's project windows, VI hierarchy, and linking behaviors than cryptic Makefiles and 10 pages of compiler warnings/errors. It's all a function of what toolset you're used to working with, and the discomfort you feel when you move to a different workbench.

QUOTE

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.

Actually, it's generally very deterministic. Unless you're misusing the word?

That having been said, I can sympathize with you. LabVIEW is pretty aggressive about the way it tries to resolve subVI linkages, and even though the dialogs and warnings you get are a lot more helpful than they used to be (there was a time when there were no cross-linking messages -- it just happened invisibly!), as a novice user it's hard to understand when you've gotten yourself into a ditch until you've driven several miles in it.

[HChandler]

I guess it's deterministic, but I havent been given the decoder ring that clues me in to what it's going to do in response to something I do.

OK, Enough of the whining.

A question. LV will only crosslink with vi's on the disk/volume/partition where the parent vi lives? True?

If this is true, what I should always do when reorganizing projects etc is to create the new development space on a pristine disk. Yes????

OK, a little more whining. My biggest mistake was trying to use the files tab in the project manager to reorganize my development space.

Every time I try and use it, it crashes the entire project!!

It seems like the files view is how LV was trying to deal with the paradox of linking with fixed linkages that are already loaded in memory. This would be fine if they want to do some juggling behind the curtain. But, it seems to really hose things when, as it allways seems to do, it crashes while the balls are still in the air.

[Michael Aivaliotis]

QUOTE (HChandler @ Sep 8 2008, 08:11 AM)

OK, a little more whining. My biggest mistake was trying to use the files tab in the project manager to reorganize my development space.

Every time I try and use it, it crashes the entire project!!

Actually, that is a known issue. I'm not sure if it was resolved in 8.6 or not. I reported it http://forums.lavag.org/Move-on-disk-feature-crashes-LabVIEW-t9040.html' target="_blank">here (and to NI).

[Yair]

QUOTE (HChandler @ Sep 8 2008, 06:11 PM)

A question. LV will only crosslink with vi's on the disk/volume/partition where the parent vi lives? True?

False, and therefore, the answer to the second question is no.

By default, every LabVIEW object that holds a path to another (VIs, projects, libraries, etc.) keeps the path as a relative path (or a symbolic path, for VIs in special folders), and only holds an absolute path if it can't (e.g. if it's on another drive).

However, if you have Foo.vi in memory loaded from X and you open a VI (bar.vi) which expects to find Foo.vi at Y, you will get a conflict, since Foo.vi is already in memory. LabVIEW will alert you to this conflict using the dialog.

If you now save bar.vi, it will remember that Foo.vi needs to be loaded from X, even if X is on another computer.

[HChandler]

That gol darn files tab is probably the worst possible thing to do since when it crashes, it leaves multiple same-named vi's wherever they were whenever it crashed. I can't beleive that LV released this "feature". The way it is it's just a booby trap.

So If I'm reorganizing, I should move things around the filesystem before firing up LV being careful not to allow multiples of same-named vi's around?

Also, what about lvlibs. Should I use them or not? Should I take things out of them before moving things around?

How about LLBs? I don't use them now but are they a better way to go for portability?

I need a strategy that works.

[jzoller]

My apologies if this is too basic.... The explicit pathing rules are under Tools>>Options>>Paths>>(dropdown)VI Search Path.

From the help:

QUOTE

<topvi> refers to the directory that contains the top-level VI that LabVIEW is opening. <LI><foundvi> refers to a list of all directories where you have previously located a subVI. During a search, LabVIEW adds to this list any directory in which LabVIEW finds a subVI. <foundvi> helps you locate a directory of VIs that has been moved or renamed. When you open a VI that calls another VI that has been moved, you must find that directory only once and then LabVIEW adds this path to the list of directories. <LI><vilib> refers to the vi.lib directory in the LabVIEW Directory. <LI><userlib> refers to the user.lib directory in the LabVIEW Directory. <LI><instrlib> refers to the instr.lib directory in the LabVIEW Directory.

Problems usually happen at <foundvi>. LV finds one VI in a location you don't like, and promptly sucks in the entire hierarchy from that location, whether you intended it or not.

Practical solutions:

1. Common vi's library, covered admirably above.

2. Name mangling - lvlibs do this (after a fashion), but the more traditional method is prefixing your vi's with purpose names. In my reuse lib, I prefix everything with "COMMON_".

3. Hiding things you don't want - When you're recompiling, if you understand the above pathing, you can rename/remove/zip folders to remove them from the pathing for the duration of the recompile.

4. Standard distribution & package management of source code - Also covered above, with addenda: I'm using an installer for package management. No software required on the target machine that way.

-Edit- When IE attacks...

Joe Z.

[Yair]

QUOTE (HChandler @ Sep 8 2008, 08:57 PM)

So If I'm reorganizing, I should move things around the filesystem before firing up LV being careful not to allow multiples of same-named vi's around?

That's the basic point, although you can have LabVIEW open. You just need not to have the VIs loaded. I'm not sure what effect this will have on projects, since I'm not an 8.x user (yet, at least).

QUOTE

Also, what about lvlibs. Should I use them or not? Should I take things out of them before moving things around?

I'm not sure. My understanding is that when you add a VI to a library, it remembers that it's owned by that library. I'm not sure what will happen if you open the VI and it can't find the library or vice versa.

You probably don't want to use LLBs. They were originally created to allow long VI names in Windows 3.x and pose some problems since they are a single file for multiple VIs.