LabVIEW-project conflicts are necessary?

[3d0g]

This is my first time sending content to this forum (vs just reading others' contributions), and I request you have some patience and not attack me too bad for my not burning unrecoverable time searching for my topic for hours, first, but, rather, just assuming it isn't present or is so hidden I'd never find it without an exact-string search. 

I've been gathering experience with LabVIEW for a bit now, although I'm, more often than not, in awe hearing you folks, and I've puzzled over something that bugs me; so I figured I'd drop it in here and see what you all say.  Now granted, I could spend my time trying to discern this answer for myself, through trials and many errors, but I hear many LV veterans in here, and I saw it as just making too much sense to send my issue into the fray and let the chips land, wherever, even if I should get chewed for not seeing the stupidity/naivety of my point of view.

So what is the issue, already?  Thank you for asking.  I hate it when LabVIEW decides that just because I brought in a file with the same name as another file into the project it just can't figure out which file I mean to use with another file.  I find it downright annoying when I suddenly get conflict after conflict after conflict and must resolve each, one by one, simply because LabVIEW, even though it could and does search under every single rock you never even knew existed to find just that little speck of a file and destroy your project, just can't figure out what you really meant and hasn't the ability to make an assumption based on context.

But I've reasoned it out, and I say this.  There should be a way to see LabVIEW having the intelligence to look directly under a file, and if it finds the file that is needed to just use that file and stop looking elsewhere to create conflicts and force updates and all the other features.  No, I am no LabVIEW veteran, but how about it all you veterans out there?  What say you?  Or even better, is this in fact the order of operations of LabVIEW and I just haven't realized it, yet? 

[RavensFan]

---

@3d0g wrote:

But I've reasoned it out, and I say this.  There should be a way to see LabVIEW having the intelligence to look directly under a file, and if it finds the file that is needed to just use that file and stop looking elsewhere to create conflicts and force updates and all the other features.  No, I am no LabVIEW veteran, but how about it all you veterans out there?  What say you?  Or even better, is this in fact the order of operations of LabVIEW and I just haven't realized it, yet? 

---

What exactly do you mean by "look directly under a file"?

LabVIEW references other VI files by name.  You can't have two different VI's in a project called MyVI if they come from two different places.  It has no method of telling them apart.  You might say, "well, they are saved in two different places, why don't tell them apart by that?"  That makes sense to some degree, as LabVIEW does keep track of paths to a file.  But what happens when you move those files?  Or swap two identically named files?  How would it know which is which and which one is the "correct one"?

[3d0g]

I have fileX in folderA.  FileX needs fileY and it is also in folderA, perhaps in a folder further down, maybe, maybe not.  fileY also exists over in folderD.  LabVIEW calls that a conflict and just can't understand that fileY, being is it's in the same folder, must go with fileX; no, LabVIEW sees a conflict, that fileY way over in folderD may just be the one to use.  In what universe is that reasonable?  Or, perhaps, I'm just missing something, like I said.  I'm still cutting my teeth on LabVIEW. 

[RavensFan]

LabVIEW tells files by their name, not by their name and location.  Location can be very fluid.  You move those files.  How does it know that File Y that was in Folder A is now in Folder Q.  And that the other File Y that was in folder D is now in folder12345?   it can't.

One way to have files with the same names but have their own distinct name spaces are to put them into libraries.  Then it will know that LibraryA has a FileZ while LibraryB also has a FileZ, but because those files are owned by their libraries, it knows which FileZ is which.

Also remember, LabVIEW was originally released in 1986.  Computers and the general technology of software has advance a long way in 35 years!  LabVIEW isbased on those technologically ancient foundations and it was certainly impossible then to have LabVIEW not be confused by having identical filenames for different files.  Since then, LabVIEW has evolved and things like the libraries have been added to add newer software development concepts.

LabVIEW pre-dates the rise of object oriented programming which didn't really take off until the 1990's.  LabVIEW didn't have OOP to begin with, but those features were introduced around LV 8.2 which was in 2006.

So it is really not fair to complain that LabVIEW is not doing something in a more modern way when it actually can, but you just don't realize it because you are so new to it.

[tst]

---

@3d0g wrote:

LabVIEW ... just can't understand that fileY, being is it's in the same folder, must go with fileX; no, LabVIEW sees a conflict, that fileY way over in folderD may just be the one to use.  In what universe is that reasonable?

---

Items in LV (VIs, controls, libraries, etc.) use several ways to remember where other items they are calling are located:

1. If the item is in a logical folder, then that will be used (e.g. <vi.lib>\MyCode\FileY.vi).
2. If the item is in another volume (drive), then an absolute path will be used (e.g. d:\MyCode\FileY.vi)
3. If it's in the same volume, then a relative path will be used (e.g. ..\..\..\MyCode\FileY.vi)

If the item you're referencing is not where it was expected it to be (e.g. because one or both of the files were moved or renamed), then LV starts searching for it (and you see that in the loading dialog).

As mentioned, you can't have two items with the same name loaded at the same time, so if you already have FileY loaded from another path, then you will get a load warning telling you that FileY was used from a different path and letting you see the details. As mentioned, this can be handled by using libraries for namespacing.

I'm not actually entirely sure where conflicts come in. I run into them only relatively rarely, so I never actually thought about what would cause LV to show a load warning and what would cause it to have a conflict. In the cases where I did have conflicts, resolving them can indeed be annoying, as it's sometimes hard to figure out what depends on what. LV does have some tools in the project window where you can right click on things to see what loads what and what comes from where (the files tab in the project window is useful), but it's still not a fun experience if you have many conflicting items.

The "correct" answer for how to avoid this would be to have things structured properly and not move stuff around a lot, but that's the kind of answer that isn't necessarily useful.

[crossrulz]

Mostly just reiterating here..

If you run into conflicts a lot, then you are not properly modularizing your code.  Say I have a section of code for logging.  I therefore make a "Logging" library and put all of its code inside the library.  That then puts the "Logging" namespace on the VIs when you load them from the project.  You can then copy the entire library (lvlib, vis, ctls, etc.) from project to project.  Libraries have other advantages such as scope (VIs set to "private" can only be called from VIs in the library) and just general code organization.

[billko]

It's not quite accurate to say you cannot have two VIs with the same name.  You can't have two VIs with the same name in the same namespace.

So how to avoid this?

1. Use a project.  This is your first line of defense.  Because the project file keeps track of the files for you, it will always call the same file from the same place, so unless the two VIs are in the same project, you won't have an issue with that.
2. Use libraries.  The name of the library is part of any library member's namespace, making it possible to even have files with the same name in the same project.  Using re-use libraries helps because you lessen the chances that you have several VIs named the same thing doing the same thing.
3. Use descriptive names for your VIs.  This lessens the chances that you name a VI the same name.

Anyone care to add to this list?

[thols]

---

@billko wrote:

...

1. Use a project.  ...
2. Use libraries. ...
3. Use descriptive names for your VIs....

Anyone care to add to this list?

---

1.5: Use classes. (learn OOP):

https://www.ni.com/sv-se/support/documentation/supplemental/06/labview-object-oriented-programming-f...

[cbutcher]

What's the goal that you're trying to accomplish?

If it's having multiple files with the same VI name, then as has already been mentioned, the solution is to ensure that they don't have the same "qualified name", which includes the lvlib/lvclass parts (e.g. "MyLibrary.lvlib:MyClass.lvclass:MyVI.vi" instead of just MyVI.vi). Only matching qualified-names cause conflicts.

If instead the goal is to replace one VI with another (in a different location, with the same name), and the problem is that you have to go through the conflicts box over and over, the solution is to avoid loading the old VI before you load the new one. The easiest way (imo) to do this is to (temporarily) delete the original VI before opening the project.

Then, the loading dialog will appear (because it can't find the VI - you just deleted the old one that your other VIs are expecting to find) and you can navigate (once) to the new VI. Then you get a dialog that tells you something like "MyVI.vi was loaded from an unexpected location" and you can see all the affected VIs (i.e. the callers, mostly).

After you've saved-all, you can go back and restore the old VI - the VIs that you just had loaded by your project have now been relinked to the new VI.

If you want to sometimes use one VI, and sometimes use another, this is a different problem. You can look for posts about loading VI references by path, and "plugin"-like systems. But that's probably a guess too far for this thread (if you do want this, maybe start a new thread to get clearer help).

[3d0g]

I'm very new to these forums, and even though I am responding to you, in reality I'm responding to others who said the same thing as you, as well.

I don't tend to add a supporting vi to a parent/super (I guess you'd could call it) vi and then go and move it to other side of the map in an unrelated folder.  That's an operation that, as I see it, is unreasonable.  Apparently it's reasonable to NI and LabVIEW, though, and all of you, somehow.  You just up and move vis all around.  To me that's weird.  I don't get that.