How to make a new version of set of LV 2017 codes

[colorimeter]

I would like to make a new version of a set of LabView code. This is my first LabView project and it's important I don't mess up the orignal code, which is in a directory with many subdirectories, containing vi's, projects, and .NET dlls. I tried to copy the parent directory to a new directory with a new name, but after editing, now both the new code and the original code don't work, with errors about the subvi's being broken and dlls not being found.

I am asking my system IT person to restore the directories to a date before I edited it. At that point, I want to make a new version that doesn't break the old one.

Where should I get started on learning how to do this? 

[billko]

You must be new to (serious) software development, not just LabVIEW, or you would be using versioning software.  Go and immediately download something like SVN with the Tortoise shell (TSVN), create a repository, then commit the original code to it.  You don't want to have to rely on IT to restore directories and folders ever again.

[Gregory]

The best way would be to use a source code control tool so that you check out a local copy in a very controlled way. It's strange that you broke the original code as well when you made the copy, that tells me the original code probably had some strange references and linking in it. 

[colorimeter]

Well, I am lucky; the code author (no longer here) did back up the original in a source control system. We are working in a "one person writes the code" mode, and now I'm that person. I would like to make a new working copy of the original code (lvproj's, vi's, subvi's, .NET dll's, any other dependencies) that I can then rename and edit.  Should I use the "save for previous" trick here, where I choose my present version of LabView, which happens to be 2017?

[paul_cardinale]

File -> Save as -> Entire hierarchy 

[colorimeter]

Will that get all the .NET dlls too? Thanks.

[colorimeter]

I am a LabView beginner and have inherited as set of complex code (many vi's, projects, sub vi's, and .NET dlls) that was kept in a main directory. I tried to make a copy of this directory and edit the vi's under the the copied directory, and the code stopped working, even in the original directory or in entirely separate directories that I didn't change. One symptom is that the vi's, which used to work fine, now ask the user to manually browse for the location of .NET dll's or sub vi's. I restored the original code (in this question here) but the code still asks for the location. There are many copies of the subvi's and dll's with the same name in many locations. When I choose what seems to be a reasonable location I get a 'Load and Save Warning' that says 'Dependency loaded from new path'.

Is it possible to restore the original path to load dependencies from? I am working in Labview 2017.

[Gregory]

The way you would usually (simply) work with source code control is

• Check out Rev 1
• Make some changes, test them out
• Check in Rev 2

If you later find a fatal error with Rev 2, you can just go back to Rev 1, no harm done. Check in can get complicated when multiple people are working on the project, because there can be conflicts you have to sort out.

When you check out a copy of the code, you will get everything that was originally put in there. Some projects, especially ones working with hardware, will require you to install some drivers, which is not done automatically when you check out the code. Hopefully the previous developer made some good documentation for what drivers need to be installed.

Now that you are asking about .NET DLLs, I'm wondering if you just need to install the drivers. Are you working on a fresh machine where you haven't run the code before? This could be why even when you opened up the original copy of the code it looked broken.

[colorimeter]

I haven't changed computers, nor edited the dll's. But your question about computers makes me add this detail:

The code is on a shared network drive. I was able to run it from the shared drive on the lab PC. I then edited it on the network drive from another laptop and later ran into trouble running it on the lab PC, with a lot of crashes. At that point the lab PC was having dependency problems (asking to manually choose sub vi's and dll's) even on code outside the directory that I edited. I then restored the code on the shared network drive, but the dependency problems remain. It's like LabView has forgotten the locations it used to have stored, for the dll's and sub vi's. I wish I knew how to restore the locations.

[Gregory · Accepted solution]

LabVIEW code often references things by relative path. That means if you have two VIs in "C:\MyProject\SubVIs" and one calls the other, the caller just knows the VI it's looking for is in the folder with it. If you move that VI to a new folder, it's not going to look in "C:\MyProject\SubVIs" the VI to call, it's going to look in its new folder. There are some exceptions to this, like the LabVIEW system folders: vi.lib, instr.lib, and user.lib.

For this reason, I keep all the code for MyProject in the MyProject folder, and no code from other projects go in that folder. (vi.lib and drivers for NI hardware excluded). Each project gets its own LabVIEW project file (.lvproj). This helps to avoid cross-linking and missing VI problems. Using LabVIEW libraries (.lvlib) will help with name-spacing problems as well. We often make SubVIs with the same name (for example init.vi), but if you put them in lvlibs for Device 1 and Device 2, then the full names of the functions will be Device1.lvlib:init.vi and Device2.lvlib:init.vi.

Code should not be run from a network folder, because then you don't know who might have been opening it. Someone might get a lot of missing VI prompts but they just click through because they want to check something. Usually, opening up the project on the development PC will be able to resolve the problems, but sometimes you'll have to browse for the missing VIs, which can be very hard if you aren't familiar with the code.