LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

How to properly transfer this .lvproj to another computer?

Solved!
Go to solution

Yes I am seeing now that is the only .vi that shows up in the project explorer, but that was not my intention. I was assuming that if I copied the .lvproj file that all of the subfolders would still show up, but would just be disconnected with warning icons and such. Apparently that is not the case. 

 

Ok, so in the case of getting this .lvproj up and running on this other computer, I need to find the directories for the instr.lib on the host computer, them copy them to this other computer, ensuring to use the same file path? 

 

Also, this .lvproj seems rather messy. I'm not even sure how to clean it up. And is it possible/recommended to move all of the dependencies up to the root directory? I just don't want to mess it up. There are soooo many dependencies in subfolders. Seems there may be hundreds. 

0 Kudos
Message 11 of 25
(953 Views)

Ok, thank you. You are saying I need to move everything (except user and driver libraries) and everything under dependencies to the project directory? Is that as simple as clicking and moving them up or do you have recommendations for that? 

 

This project seems rather messy and there are more dependencies than I've ever seen in a .lvproj up to this point. Hundreds probably through the subfolders. It looks like several VIs, SubVI's, and code in general from other projects were pasted/added to this one. Many files I'm not sure what they are yet. I just don't want to go moving this huge mess of dependency files up the the main directory and have something go wrong. 

0 Kudos
Message 12 of 25
(950 Views)

@Kastun27 wrote:

I was today's years old when I discovered SCC for LabVIEW. I've barely used repositories for anything actually. Just grabbed a few things from Github here and there. I'm watching some videos now and reading what I can. I see that they seem to be primarily used for pushing changes with multiple developers. I watched this video as it seems to come up in every search.

 

http://delacor.com/configuring-hg-or-git-to-use-labview-compare-and-labview-merge/

 

The business I am at is small and there are no other developers. There are only 2 or 3 computers that LabVIEW is being used. I love the idea of having a respository for LabVIEW...and this may be a silly question...but am I able to use this method to clone an entire .lvproj to another computer? Or is it just to push changes on .lvproj's that have already been cloned to another computer via some other method? 


Certainly!  That is what SCC does.  It puts a copy of Source code on different development machines and synchronizes the changes made wherever the source is checked out. 


"Should be" isn't "Is" -Jay
0 Kudos
Message 13 of 25
(948 Views)

Ok. Pardon me but I'm trying to understand all of this. It seems like there are multiple methods of moving a project to another computer. From what I've learned so far:

 

1. Carefully and methodically copy the project with included file paths and such

2. Use the application builder and know how to use it correctly

3. Use a SCC repository

 

Is that the gist of it? And which method you use is a matter of preference and/or experience? 

0 Kudos
Message 14 of 25
(939 Views)

@RTSLVU wrote:

Or if you don't want to copy the whole project including insr.lib and user.lib make a new "source distribution" of the top level vi and copy that over.


Be aware that this does not include the project file, so you will not have the project layout, build specs (including installer upgrade codes) and other useful information. You can manually copy the lvproj file to the new destination and it will "mostly" fall into place. (I have automated that process, though).

 

(See also)

0 Kudos
Message 15 of 25
(930 Views)

@Kastun27 wrote:

Ok. Pardon me but I'm trying to understand all of this. It seems like there are multiple methods of moving a project to another computer. From what I've learned so far:

 

1. Carefully and methodically copy the project with included file paths and such

2. Use the application builder and know how to use it correctly

3. Use a SCC repository

 

Is that the gist of it? And which method you use is a matter of preference and/or experience? 


I have always used method #1 

You just have to be disciplined to keep your projects clean and organized.

 

I don't understand how #2 would work

 

It would be nice to be allowed to use our company's software source control. But those snooty text based programmers don't think I should be allowed to, and they control it.

========================
=== Engineer Ambiguously ===
========================
0 Kudos
Message 16 of 25
(928 Views)

@RTSLVU wrote:

@Kastun27 wrote:

Ok. Pardon me but I'm trying to understand all of this. It seems like there are multiple methods of moving a project to another computer. From what I've learned so far:

 

1. Carefully and methodically copy the project with included file paths and such

2. Use the application builder and know how to use it correctly

3. Use a SCC repository

 

Is that the gist of it? And which method you use is a matter of preference and/or experience? 


I have always used method #1 

You just have to be disciplined to keep your projects clean and organized.

 

I don't understand how #2 would work

 

It would be nice to be allowed to use our company's software source control. But those snooty text based programmers don't think I should be allowed to, and they control it.


I have always used method #3 myself. The downfall of method 3 is that is misses any instrument drivers that might have been installed in vilib. To get around this short-sighted approach of handling instrument drivers, I usually go through the pain of putting the instruments drivers in a common directory under SSC so no one needs to install the instrument drivers.

---------------------------------------------
Certified LabVIEW Developer (CLD)
There are two ways to tell somebody thanks: Kudos and Marked Solutions
Message 17 of 25
(915 Views)

I am assuming its a much better practice to begin the project in SCC from the beginning while keeping everything organized properly.  Unfortunately, in my case I would be hosting this mostly completed project that seems to be rather involved and fairly disorganized. I suppose the only good thing about it is that it is local, and no one else is messing with it or needs to use it. Are there known problems you think I might encounter in this situation? 

0 Kudos
Message 18 of 25
(908 Views)
Solution
Accepted by topic author Kastun27

When I looked at your Project file, there didn't seem to be a whole lot of sub-VIs.  But what do I know?

 

If I "inherited" a PC with a disorganized LabVIEW (little-p) project that had a few hundred VIs scattered hither and yon, and I want to make a "Project" out of it, here is what I would do:

  1. Make a Folder with a meaningful name.  "BS Inherited Project".
  2. Move (not copy) the Project folder into it.  For "good luck", I might rename it to "PROJECT BS Inherited Project" (though I might wait until after everything else has been moved).  Note that if I didn't even have a Project File, I'd just skip this step.
  3. I'd make a series of sub-Folders.  "Documentation".  "Data".  "Types".  "Sub-VIs"  "Resources".  I usually do not make a Folder for "Top Level VIs", as there are usually one (or maybe four).
  4. Copy the Top Level VIs into the folder.  Open each, note "what is missing" (what fails to load because it can't be found).  Find it, put it in the appropriate Folder in your Project.  Open the Top Level VI again, and when it says "Can't Find MyFirstSubVI" (that's not the message, but it's equivalent to that), use the opened File Browser to find the missing sub-VI in the Project Folder where you stashed it.  Repeat as much as you can.
  5. Things in LabVIEW Libraries should "find themselves" (because vi.lib, instr.lib, and user.lib are in known locations)
  6. Once everything is safely located in the Project Folder, you are ready to create the Project file and populate it.  This turns out to be fairly easy.  In fact, it is almost easier to make a new Project File from scratch at this step, which is what I'll describe:
    1. Rename the old Project File ("My Old Project File").
    2. Create a new Blank Project (from the Getting Started With menu, New Project).
    3. Immediately do a Save As, navigate to your Project folder (if you are not already there), and give the Project the name you really want to use (anything but "Untitled Project 1").  You now have an empty Project in the Project Folder with the Top Level VIs and all its "other parts".
    4. Select "My Computer".  Right-click it and say "Add Folder (Snapshot)".  When you finish, all of your files and folders will appear in the Project, along with the Folder in which you saved them.  If you open the Top Level VI, everything should follow.

You now have a Project with VIs, TypeDefs, and other files organized in Physical Folders (what you made on the disk) and "Virtual Folders" (what the Project has created).  I use the Project design where Physical and Virtual Folders are identical.  So if I move my Project (Folder) to another PC, all the (disk) files come with it, and will be automatically relocated when I open the file on the new machine.  Files in standard Libraries (vi.lib, instr.lib, user.lib) should be present on the other PC (I'm assuming LabVIEW has been installed), though if you use other Third-Party Libraries, you'll need to move them separately.

 

On another topic, about a year after I started using LabVIEW, I started using Subversion for keeping track of my work.  What a joy, and what a necessity that is!  No more copying onto a USB Key (and trying to keep track of multiple versions).  Migrating my Project to a new Machine is as simple as doing a CheckOut on the new Machine -- the latest version of the code pops right up.

 

Bob Schor  

Message 19 of 25
(890 Views)

Bob, I'd say you know a thing or two about a thing or two.

 

Thank you for the detailed response. Extremely useful information that I will heed. I also looked into TortoiseSVN. It seems to be the way to go since this is a small company and there can be a local repository on their shiny new server.

 

I apologize for being dense, but I'm still not sure how to handle all of these dependencies I am seeing on this project. I have attached a screenshot of several of the .vi's under dependencies. I'm not even sure how many their are. Might be 2,3, or 5 times as many as you see here. Lots of virtual folders that just keep opening. It seems crazy to arbitrarily move them up the project. Or if I used TortoiseSVN would it just do it's thing and handle them accordingly? I'm pretty lost on this one.

0 Kudos
Message 20 of 25
(873 Views)