LabVIEW Idea Exchange

About LabVIEW Idea Exchange

Have a LabVIEW Idea?

  1. Browse by label or search in the LabVIEW Idea Exchange to see if your idea has previously been submitted. If your idea exists be sure to vote for the idea by giving it kudos to indicate your approval!
  2. If your idea has not been submitted click Post New Idea to submit a product idea to the LabVIEW Idea Exchange. Be sure to submit a separate post for each idea.
  3. Watch as the community gives your idea kudos and adds their input.
  4. As NI R&D considers the idea, they will change the idea status.
  5. Give kudos to other ideas that you would like to see in a future version of LabVIEW!
Top Authors
cancel
Showing results for 
Search instead for 
Did you mean: 
nm123456789

Relative Paths

Status: New

The use of true relative paths would greatly improve team collaboration of Labview projects for several reasons.

 

  1. Not everyone uses the same exact path to their libraries, sub VIs, etc. It is extremely unproductive and annoying when you are working in a team environment and say a co-worker needs to check his sub VI with the main project, he gets it working, and then checks in his work. You check out the work, open in the main VI, and Labview asks where is XYZ.vi is and then you relink it. You need to complete this process every single time the project goes back and forth between the two workers. This is even more annoying when there are tons of VIs that need to get updated or there are several people on the project where work is split up into logical components.
  2. Relative paths would allow for better use of version control systems. After checking out a local copy of VIs, say one folder is named Libraries and contains the sub folders Lib1 and Lib2 and another main folder is called Projects and you have Proj1 and Proj2. Who cares if the local repo copy is located on the C: drive or 😧 drive or buried deep somewhere on your computer. The file structure of your repository will be the same no matter where you put it. (You guys push version control at seminars – and I’m glad that you do – but it’s even harder to use without relative paths.)
  3. Almost every single programming language's IDE, design tool, and even office suites support relative paths.
  4. Even if you are a standalone team and say your computer dies but you have all of your work stored on a repository or backed up on a network drive. When you get your new computer up and running and place your files back on your computer but say a slightly different location, again you have to go back into your project and relink everything to the correct path.
  5. Productivity would increase!
  6. I’m sure there are several other examples but I’m hoping you get the idea.

Maybe relative paths would only be supported if you created a new Labview project and specified relative paths in that project. This seems the most logical place to put them.

 

Please please please add in support for relative paths. Robot HappyThanks!

24 Comments
GregR
Member

LabVIEW uses relative paths except for 3 special cases:

  • The files are not on the same drive (or under same root directory on Linux)
  • The referenced file is in one of LabVIEW's special directories (eg. vi.lib, user.lib)
  • The library for a call library node is referenced by name only (no path given)

You may be getting confused because LabVIEW tends to always show you absolute paths, but we save these as relative paths and simply compute the new path before showing it to you. If you find the common root directory of all your VIs, you should be able to move that directory anywhere on your machine (or even onto a network drive) and all the paths will be fine. If you rename or move directories within that common root directory, then you will likely cause problems.

nm123456789
Member

 

@GregR

 

Let me try to clarify further say my repo looks like:

 

C:\

Labview

   +Projects

      -Project 1

         - Sub VIs

   +Library

      - Lib 1

      - Lib 2

      - Lib 3

 

Say my project is in Project 1 and it's using all of the Sub VIs in "Sub VIs" and "Lib 1" and "Lib 2." Are you saying it will find all files in "Sub VIs"?  What about finding all of the the library files located in "Lib 1" and "Lib 2"?

 

Now say somebody else has a repo checked out that looks the same expect:

 

C:\My Stuff\My Labview Stuff\Labview Repo\

Labview

   +Projects

      -Project 1

         - Sub VIs

   +Library

      - Lib 1

      - Lib 2

      - Lib 3

 

and they open Project 1. Will Labview find everything without asking where everything is?

 

dthor
Active Participant
  • The files are not on the same drive (or under same root directory on Linux)

GregR, why is this the case? I don't see why the C drive is different from the E or Q drive. I personally would classify this as a bug, unless you can tell me otherwise Smiley Very Happy

GregR
Member

@nm123456789 wrote:

Will Labview find everything without asking where everything is?


Yes, that case is exactly what it is built to handle. A VI in the subVIs directory referencing a VI in the Lib 1 directory would store a path of ..\..\..\..\Library\Lib 1\ViName.vi. (This may seem like one extra up but we do the path calculation from a path that includes the original VIs name so the first .. just removes that.)

 

As long as you avoid the special cases I mentioned, this will be the behavior. The most common errors I see people make are forgetting about some set of VIs that are referenced from higher in the heirarchy than they thought or mixing putting VIs under user.lib on one machine and not under user.lib on another. Avoid these and you should be fine. 

GregR
Member

@dthor wrote:

I don't see why the C drive is different from the E or Q drive.


The C drive is not any different. "The files" in my comment are the caller VI and its subVI or the project and its referenced VI. Assume a.vi calls b.vi. If a.vi is on the R drive and b.vi is on the G drive, storing a relative path between these would mean storing enough ..s to completely encode the depth of the path to a.vi on R and we would then also store the entire path of G of b.vi. If the depth of a.vi's path on R changed, we would then be looking for G as a folder at some other level rather than as a drive. It just doesn't make sense to store relative paths in this case.

 

This has nothing to do with what drive a particular person puts their files on. It only relates to each particular copy of the project being contained on a single drive.

nm123456789
Member

 

Okay so I was messing around and see that this type of file structure works:

 

C:\

Labview

   +Projects

      -Project 1

         - Sub VIs

   +Library

      - Lib 1

      - Lib 2

      - Lib 3

 

Why doesn't a file structure like this work?

 

C:\<doesn't matter what goes here>

Labview

   +Projects

      -Project 1

         - Sub VIs

Library

   + Lib 1

   + Lib 2

   + Lib 3

 

If a project was looking for a library file shouldn't it know that it needs to get out of Labview and then go one deep into Library?

 

TCPlomp
Trusted Enthusiast

Are you sure that your latest example doesn't work?

If I understood you correctly you have the 'Labview'  and the 'library'  folder in the same (main) folder?

If that's the case you should be able to move those two folder around.

 

However if you are moving from one method (projects and library as subfolders) to another (labview and library as subfolder) you will experience relinking issues.

 

Ton

Free Code Capture Tool! Version 2.1.3 with comments, web-upload, back-save and snippets!
Nederlandse LabVIEW user groep www.lvug.nl
My LabVIEW Ideas

LabVIEW, programming like it should be!
nm123456789
Member

That's correct. So C:\<something>\Labview\........ and C:\<something>\Library\...... and <something> is exactly the same. 

SteveChandler
Trusted Enthusiast

nm123456789, what's with all the javascript? What are you using to post here?

=====================
LabVIEW 2012


nm123456789
Member

@SteveC. I'm not sure with regards to the javascript. I'm just using IE 7. (It's kinda annoying though.)