Make libraries and VIs less environment aware

[Miha_Vitorovic]

I just downloaded a library and a project it was developed in. I tested it, and everything works fine. Then I copied the library (.lvlib, all .vi files and preserving folder structure) to a new project, but when I open it I get a conflict saying that the same library is defined twice? A conflict that cannot be resolved BTW.

I spent 30 minutes just getting out of the mess this puts me in. The result, project2 is now OK, but project1 now complains that it has duplicate code. Come on! I know I have two copies of the same library! I want to have two copies of the same library! Why can't LabView just use the "local" version and not complicate my life with something that happens to lie on the disk somewhere and has absolutely no connection to the current project?

[Intaris]

Maybe because it DOES have a connection to the project.....

Problem might be home-made?

[Miha_Vitorovic]

I opened the lvlib file in the text editor to find any absolute link. I couldn't find one.

Also, I didn't modify files in the original (library) project in any way, but when I open that project it says that it is in conflict with the newer (my) project. So, even if there was some hidden direct link from the copy to the original, there should be no link from the original to the copy. Right?

[AristosQueue (NI)]

> Also, I didn't modify files in the original (library) project in any way,

Yes you did. You may not realize it, but you said you did in your original post.

> but when I open that project it says that it is in conflict with the newer (my) project.

> So, even if there was some hidden direct link from the copy to the original, there should be no link from the original to the copy. Right?

Because I am *very* certain that the project only reports conflicts when they actually exist, I'm willing to bet that you did something to create the conflict. Once created, it actually is not a surprise to me that you cannot work it out -- those are notoriously hard to untangle once created. It's why we added the conflict detection layers to the project so that they never get created in the first place.

I'm going to try to walk through what I am guessing happened. This is only a guess, but perhaps it is at least right enough for you to figure out what actually went wrong. I can only help a little bit with "how did the conflict get created." There are many paths a user may choose that lead to that doom. What I can help a lot more with is explaining how the original got tangled up once the conflict did exist and you tried to resolve it.

You downloaded Original Project that references Original Library. It opened and opened just fine.

Now you "I copied the library (.lvlib, all .vi files and preserving folder structure) to a new project". There's a couple of things this could mean. Option A: you copied all the files on disk -- the project file, the library file, all the VI files -- to a new directory and then opened the copied project file. Option B: You were inside LabVIEW and you did some sort of "File >> Save As..." operation to copy the library. My bet is that you were inside LabVIEW and you used one of the Save As options that only duplicated the library file (.lvlib) and did NOT duplicate all the VIs in the library. I could be wrong, but that's the usual way these situations come about.

So now you open a new project and load the copied library. It loads, and it loads all the original VIs. Each of those original VIs points to the original copy of the library as being their owning library, so the project detects the conflict and says, "You have asked me to use New Library. I have detected that New Library uses Old VI and Old VI uses Old Library. Old and New Library cannot be in the same project together. Pick one."

Now you go to the trouble of resolving the conflicts. That dialog is painful to use, yes? It's kind of meant to be. It double checks at every step and has way more information than most people want to think about. Why? Because the project detects a conflict before your files are permanently cross-linked, but as you resolve the conflict, you are committing changes to the referenced paths of the various files involved. We are very explicit in showing you path information, which file references which other file, and making you accept the changes to each and every updated link because sometimes you have to inspect each link to find the one that is messed up.

Often the fastest way of resolving a conflict is to go to the project window... at the top of that window, you'll see two tabs, Items and Files. If you click on Files (shortcut key ctrl+E), you can see where all your files are laid out. Most projects have all their pieces in one directory (sometimes a second directory for shared libraries). It is often very easy to see, "Hey, that's file that is listed is from a directory that I don't expect to ever see in my project." You can then popup on that item and find the callers to see who is including the errant file. Now back to my guess about your story...

In this case, my guess is that you told each VI, "You should use New Library." Once the conflicts were resolved, every VI saved to disk. Now New Project looks good. New Project loads New Library and New Library uses Old VI and Old VI uses New Library. Great... until you go back to load Old Project. Because you've changed the VIs (which both libraries claim as their own), now the Old Project sees a conflict when it tries to load Old Library.

> I know I have two copies of the same library! I want to have two copies of the same library!

There is a difference between having two copies of the same library file and two copies of the same library, which means duplicating not only the library but also all the VIs therein.

I could be way off base with what happened in your actual work. I'm guessing based on observations of other customers and the description you gave originally.

> Why can't LabView just use the "local" version and not complicate my life with something that

> happens to lie on the disk somewhere and has absolutely no connection to the current project?

LabVIEW tries to do exactly this, but each file has instructions about where to look for its subVIs, owning library, etc. Copying files in LabVIEW is not the most pleasant experience, I admit. We have this problem of interconnected files. Since not everyone works in a project, an individual file cannot just say, "I use other file named XYZ" and then leave it to the project to figure out which XYZ to use. Every file dictates what other files it relies upon, and when two of those meet in the project, their dependencies may create a conflict. That's why we detect such conflicts in the project and try to give you the options for leaving some files out.

I hope this helps. Conflicts in LabVIEW are among the *worst* problems. We have tried to create tools to help the situation, but, as your experience demonstrates, the problem is far from solved. If you have any more specific ideas for helping, please share them in the Exchange. Unfortunately, from your description, this Idea sounds like LV already working exactly as intended. 😞 Good luck.

[Miha_Vitorovic]

Thank you for the verbose description of what I could be doing wrong. But it doesn't describe my problem, because in the step where I copied the lvlib and vi files I used "OS copy", not the "LV save as". Then in the second project I used "Add/File..." and pointed to both .lvlib files.

When I find the time one of these days I will try to recreate the problem using a fresh version of the same library and record the steps on the way. If I get the same error, I will post the recipe here.

[AristosQueue (NI)]

> Then in the second project I used "Add/File..." and pointed to both .lvlib files.

You tried to put both library files in the same project. That *is* the conflict. You can only use one file of any given name in a single project. Then when you untangled, I bet you got some VIs originally from library A pointing at library B and vice versa, leading to modifications of the original.

[Miha_Vitorovic]

I'm sorry I wasn't more clear in my orginal post. The original project contains 2 libraries. I will create a "walkthrough" and see if it takes me to the same problem. Anyhow, I have a feeling that should a problem arise one more time I better take this through the normal support channels and not litter this forum with it, since it is obviously a bug of some sort (but we will have to see if it is a user bug or a product one :))

[AristosQueue (NI)]

> (but we will have to see if it is a user bug or a product one :))

Sounds good. I wish you luck.

[TCPlomp]

I think I may have experienced the same issue.

And I think I found the reason:

1: Create an lvlib inside vi.lib\foo\bar.lvlib

2: Create a VI vi.lib\foo\zeta.vi

3: Add the VI to the lvlib

4: Copy the foo folder out of vi.lib to a folder fooclean

5: Create a new project fooclean\foo.lvproj

6: Add bar.lvlib to the foo.lvproj

7: LabVIEW will generate warnings

I investigated this and openend the bar.lvlib with a text editor. It turns out that the library has absolute paths to the files inside vi.lib, not relative paths too ..\zeta.vi as I would expect.

The other part of the problem is that zeta.vi has a relative link to bar.lvlib (as far as I can understand).

So at the end of the test:

-fooclean\bar.lvlib points to <vi.lib>\foo\zeta.vi

-<vi.lib>\foo\zeta.vi points to <vi.lib>\foo\bar.lvlib

I conclude that it's a bug inside the project/lvlib/xcontrol/lvclass environment that a path inside vi.lib is always stored as an absolute path while it might be better  to use a relative path.

Ton

[AristosQueue (NI)]

> I conclude that it's a bug inside the project/lvlib/xcontrol/lvclass environment that a

> path inside vi.lib is always stored as an absolute path while it might be better  to use a relative path.

Since time immemorial (which translates as "before I started working on LV in version 6.0"), a VI records the paths of its subVIs as relative paths unless those VIs are inside vi.lib or instr.lib. The "psuedopaths" are not absolute paths. They are pseudopaths because they go to whereever vi.lib happens to be located at the moment. When a subVI inside vi.lib is missing, there are different rules that apply for searching for the missing file than for other missing subVIs. This allows VIs to have target specific implementations and a VI will load the correct subVI for the target when it loads into memory. So, for example, you have

<vilib>\Utility\error.llb\Simple Error Handler.vi

When loading on the desktop, that pseudopath resolves to

<labview>\vi.lib\Utility\error.llb\Simple Error Handler.vi

But if the caller VI is loaded into an FPGA target, that pseudopath resolves to

<labview>\vi.lib\FPGA\Utility\error.llb\Simple Error Handler.vi

Libraries follow the same rules that VIs always have -- paths inside vi.lib and instr.lib are absolute, paths outside of those directories are relative.

There are other special cases for resolving pseudopaths. Mostly these are not a problem since the items inside these directories are generally finished code that is not directly modified. But you are trying to create a copy that you can modify. You'll need to use Save As to copy the files out of vi.lib because -- as you noticed -- copying on disk results in a copy that still points back into vi.lib.

[G-Money]

Programming issue. Naming conflicts.