What's the 'best' way to copy a usable project to new one so it can be modified without affecting the original?

[Mark.Randol]

My plan is to use most of the old project, but I'll have to repartition code a bit so it handles data better, and in a way that makes sense with the additions.  It's project specific, so the reuse later is doubtful, except for the more General Purpose vi's I've already saved off in other directories. 

Copying the project also copies the GP vi's, including their full directory structure.  Annoying...

---

@Hooovahh wrote:

---

@JÞB wrote:

Hoovahh,

If you can use %90 twice, you could probably envision a third and forth use too.  its easier to remove than add new...

those actors and engines should be in a reuse lvlib.

---

Much easier to remove then add, which is why I copied the tree and delete things not needed.  But I do agree that these actors/engines could be more reusable.  I do have them in lvlib form but many times there will be coupling between actors that are unavoidable.  If the UPS actor detects a power outage it needs to tell the sequencing actor to stop testing if a testing is going on.  For that reason I have a hard time splitting some actors into reusable modules, because they are only reusable if other components are there.

---

[Mark.Randol]

I figured someone would bring up SCC.  Since it's 'just me', how is it more than one more thing to manage?  I'd rather spend the time figuring out my application and LabVIEW than learning a SCC system.

---

@SnowMule wrote:

To me, it screams "source code control". 

But you can zip the project directory and that can provide a decent "snapshot" of the project at that time... the right answer is SCC though.

---

[Mark.Randol]

Off to give it a look.  Thanks.  Stone knives and bear skins might be more my speed tho'.

---

@JÞB wrote:

WHOA Guys!  Lets not go all old school on our friend Mark. 

LabVIEW introduced Project Templates in version 2012. 

https://forums.ni.com/t5/LabVIEW/Project-Templates-Creating-my-own/m-p/2187698#M702015

The best way (and really its pretty pain free) involves making the right edits to the metadata file and using the built in feature to script you up a fresh copy of a brand new project.

There is even a Nugget https://forums.ni.com/t5/LabVIEW/Darren-s-Occasional-Nugget-10-16-2012/td-p/2189114

---

[Hooovahh]

---

@Mark.Randol wrote:

I figured someone would bring up SCC.  Since it's 'just me', how is it more than one more thing to manage?  I'd rather spend the time figuring out my application and LabVIEW than learning a SCC system.

---

This is a poor attitude to have twards SCC.  The majority of the programs I make are on my own and I use it daily.  The benefits I get from SCC far out weigh the time needed for me to use it.

[Mark.Randol]

You saying you use it daily tends to reinforce my view.  I don't use LabView anywhere near that often, much less write code in it.

<edit - changed enforce to reinforce>

---

@Hooovahh wrote:

---

@Mark.Randol wrote:

I figured someone would bring up SCC.  Since it's 'just me', how is it more than one more thing to manage?  I'd rather spend the time figuring out my application and LabVIEW than learning a SCC system.

---

This is a poor attitude to have twards SCC.  The majority of the programs I make are on my own and I use it daily.  The benefits I get from SCC far out weigh the time needed for me to use it.

---

[SnowMule]

You can do it on AWS too... they've got pre-configured Subversion and Perforce AMI's ready to fire up.

https://aws.amazon.com/marketplace/pp/B007I9FYWU

https://aws.amazon.com/marketplace/pp/B007I8TPRG

[Mark.Randol]

---

Wow.  That's somewhat painful, but it's ~the end result I wanted. 

Part of the 'equation' is I'm working on multiple machines (development & 'production') and the code is copied via a network share.  I'm getting a lot of copying back and forth, longer directories, etc, just from that process.  (think offline files - yeah...)  So far, LabVIEW is not being helpful in managing that process, unless I'm missing something.  Entirely possible.  <edit-> Likely even.

<non-sense deleted - some of it at least>

<some more added> This I think explains part of what's going on when I'm copying. One of the suggestions echoes RTSLVU's suggestion.  Last update was 2009, so maybe there's more modern ways, but it still seems to work so far.

"Path Information When Searching For SubVIs"

 

@RTSLVU wrote:

Copy the entire project directory to a new location <etc>

[ErnieH]

If you want it simple, then here is what I do.

Put all of your Vi's in one directory. You can use the project tools to see where the VI's are. Bit of a pain, but once you have that, you can copy and paste the directory to a new location. Just have to change the build file location. Easy to hand off to others, use on another PC, archiving. No searching for files, relinking, etc. Copy, paste, and start editing. Your original files are not modified so it is easy to go back. We have 70+ programs we support like this (with many different versions) and I can get the released copy and be up and running in minutes. We also are locked our LabVIEW version down. Twice yearly updates (with the service packs) is insane if you use it in production and have systems all over the world. I don't even create installers anymore. I have one program that I use to create a directory structure and load the run time programs and drivers I use. Once the user loads this, I can simply zip up a directory with their program and distribute it.

With this method, I can edit a program, distribute the executable, and test it quickly and easily. Plus it is easy to go back to the old version on the target machine because I did not change it or run an installer for this change. My 2 cents.

[Mark.Randol]

I noticed when the VI's are relinked, even the ones in 'soft linked' directories get 'hard linked'.  That seems odd.  Am I doing something wrong during the relink process?  (off to edit the XML <?> to fix it - which the link to editing projects will likely be handy!)

[Mark.Randol]

This is mostly to remind me when I try this again in a year and have forgotten how.  I'm using LabVIEW 2012 Full.  I'll assume I'll know when to click OK, Save...

I'm copying a project I have full control over.  Specifically it's a project I want to copy a core set of VI's to then modify without affecting the original project, but maintain links to 'external' VI's which will remain unchanged.  It's things like instrument drivers and custom VI's with general application I don't want copied but want to remain linked.

0 - Open the project to be copied.

1 - From the Project Explorer, File - Save As...

2 - Chose Duplicate .lvproj file and contents, BUT click the 'Select contents to copy' radio button.

3 - Since I have some 'mid level' VI's saved in directories other than the 'high level' VI's specific to this project, I click the 'Files' tab in the 'Select Contents to Copy' pop-up.  Since the 'mid level' vi's aren't planned to be changed, I uncheck all the directories other than the 'high level' VI's which also unselects all the files contained within.  If the VI's aren't arranged like this, you'll have to pick through the files to pick which ones NOT to copy.  By default, all files are checked and will be copied.

4 - Select / Create the directory to save the copy to. 

5 - Pick a name for the new project file and Save it.  It doesn't have to be different, but it'll make it easier to tell the difference later.

6 - Done!  Start modding without worries of breaking what already works.

The dependencies are still linked to the original locations, not copied.  No crazy long paths, since the dependencies aren't copied.  Hopefully it's obvious if there are changes to the mid level, they'll need to be carefully conceived to maintain proper functionality in other programs.  Easiest / safest, just copy the 'mid level' VI into the project directory as a 'high level' VI.

Thanks to all who commented, including Sam at NI on the phone.  Sometimes forums and email aren't the most effective for communication, particularly when one of the parties (me!) doesn't fully grok the lingo. 

Mark