Relative Paths

[nm123456789]

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

[li-deanna]

 

---

@nm123456789 wrote:

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

---

(paste follow quote by NM123456789)

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

[li-deanna]

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

[TCPlomp]

Could you emphasize what isn't working?

Because I don't get/understand your issue.

Ton 

[nm123456789]

<script id="F5_watermark" type="text/javascript"></script> <script type="text/javascript">// try{F5_flush(document);}catch(e){} // </script>

---

Could you emphasize what isn't working?

Because I don't get/understand your issue.

Ton 

---

Having a file structure like this:

C:\Labview\Projects\Project 1

C:\Labview\Projects\Project 2

C:\Labview\Projects\Project 3

C:\Libraries\LV Libraries\<bunch of sub VIs>

causes linking issues when one of the three projects tries to use a shared VI in the LV Libraries folder. My question is why doesn't Labview jump up out of C:\Labview\ to get to C: and then jump down two folder to get to C:\Libraries\LV Libraries\? Having the libraries set up this way causes linking issues.

---

<script id="F5_watermark" type="text/javascript"></script> <script type="text/javascript">// try{F5_flush(document);}catch(e){} // </script>

On the other hand:

C:\Labview\Projects\Project 1

C:\Labview\Projects\Project 2

C:\Labview\Projects\Project 3

C:\Labview\Libraries\<bunch of sub VIs or even folders to group them>

This type of file structure does NOT cause any linking issues when using a shared resource, i.e. any of the sub VIs in the Libraries folder among the three projects.

Thanks!

[nm123456789]

Could you emphasize what isn't working?

Because I don't get/understand your issue.

Ton 

---

[TCPlomp]

Strange, it sound like a bug. Could you post a screenshot of the cross-linking issues?

[nm123456789]

<script id="F5_watermark" type="text/javascript"></script> <script type="text/javascript">// try{F5_flush(document);}catch(e){} // </script>

Unfortunately I cannot post a screen shot since it is happening on a different computer. However, it's just the standard "Labview can't find <file>. Please locate the file manually." There is nothing strange about the linking error. At the very least, using the file structure above works, which is no problem to use. If you find anything else please let me know. Thanks for the support.

<script id="F5_watermark" type="text/javascript"></script>

[jk010]

I have not experienced LabView treating VI paths relatively at all.  If I drag a single VI from one project folder into another, that VI's sub VI's will still reference the old folder, even if there are identical sub VI's in the new folder... What am I missing?  This is a huge headache with LabView development.  Both project folders are on a \\local... network path (we're too primitive to use version control as I'd like).

[crossrulz]

Did you do the copy while one of the projects was still open?

[jk010]

I guess the "receiving" project is usually open when this happens.  Then I manually add that file to the project from it's new copied location.  If I understand correctly, LabView is maintaining its own memory copy of everything separately from what I see on the disk? (not sure why that's a good idea but..)

[crossrulz]

Yeah, not sure about what is in memory when and all of that.  But I do find it best to copy VIs when LabVIEW does not have any project or VIs open.

[AristosQueue (NI)]

> If I drag a single VI from one project folder into another, that VI's sub VI's will still reference

> the old folder, even if there are identical sub VI's in the new folder... What am I missing?

I honestly do not know what you are doing, but I know for certain that a VI only stores three types of paths to its dependencies. Every saved path is either:

a) a pseudopath for items in vi.lib, instr.lib, etc., that resolves to the version of LV that the VI is loaded into

b) a relative path.

c) an absolute path when the dependency is on a different drive such that no relative path can be constructed.

There are never absolute paths to same-disk dependencies. Ever. I've got a raft of tests that assert that, and I can tell you tons of code would be broken if it were ever done.

When you use the phrase "project folder", do you mean a virtual folder in the project tree within LV? Or do you mean an on-disk directory that happens to contain one of your projects? If it is the latter, then when you open that copied VI, it will use the local subVIs in its new location. Now, if you open the copied VI into the original project, and the original subVIs are already in memory, then you'll get a load warning about crosslinking, but that's because you've just deliberately cross-linked. 🙂 But loading the newly copied VI by itself will always load the relative path subVIs.

I believe you when you say you are seeing something otherwise. But I also believe you're not telling me some critical piece of information. The common use case, as you describe it, works.