03-02-2021 11:47 AM
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.
03-02-2021 12:03 PM
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.
03-02-2021 12:38 PM
@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.
03-02-2021 01:00 PM
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?
03-02-2021 01:21 PM - edited 03-02-2021 01:26 PM
@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)
03-02-2021 01:25 PM - edited 03-02-2021 01:27 PM
@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.
03-02-2021 02:03 PM
@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.
03-02-2021 02:39 PM
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?
03-02-2021 05:27 PM
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:
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
03-03-2021 09:06 AM
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.