From Friday, April 19th (11:00 PM CDT) through Saturday, April 20th (2:00 PM CDT), 2024, ni.com will undergo system upgrades that may result in temporary service interruption.

We appreciate your patience as we improve our online experience.

LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

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

Solved!
Go to solution

I'm pretty much a LavVIEW newbie. 

 

I'm using LabVIEW 2012 Full on Windows 7.  I copied a project using Save As-Duplicate in Project Explorer.  It created an excessively long, complex directory structure.  It resulted in 'too long' errors (presumably from the PATH being too long).

 

The intent was to get a copy of the usable project to be able freely modify it without damaging the original. 

 

I've poked around the forums and knowledge base, didn't see anything definitive.  I'm guessing the information is already posted but I just haven't been able to find it.  A point in the correct direction would be appreciated.

 

Thanks,

Mark

Message 1 of 22
(15,569 Views)

I think the way you went about it was right.  My only suggestion would be to create the duplicate somewhere close to the root of the disk so you don't end up with too long path issues.  Same when saving a VI for previous, I always choose something like C:\temp.

 

In the past I have just duplicated the project on disk using File Explorer.  This does some times have linking issues so it is a pain to ensure that the project only links to VIs in its own project and not the duplicate.

0 Kudos
Message 2 of 22
(15,564 Views)

Bad part is, Project Explorer made copies from the root directory, all the way through the vi locations.  That seems entirely unnecessary.  Is there a toggle somewhere in the settings to modify that behavior?

0 Kudos
Message 3 of 22
(15,553 Views)

@Mark.Randol wrote:

Bad part is, Project Explorer made copies from the root directory, all the way through the vi locations.  That seems entirely unnecessary.  Is there a toggle somewhere in the settings to modify that behavior?


The Save function can't know the relationship between any two VIs any more then the compiler would.  So to ensure that linking works as expected it just duplicates the whole directory structure.  That way the relative path from any VI before the save will be the same after the save.

 

Yeah it is a pain, which is another reason I just copy the project folder that I know contains all the code for that project not including user.lib vi.lib or any other shared locations.

0 Kudos
Message 4 of 22
(15,550 Views)
Solution
Accepted by topic author Mark.Randol

Copy the entire project directory to a new location

Delete the .lvlps, .lvprog and .aliases files from the new copy

Start LabView and create a new blank project

In the project manager add a new auto populating directory selecting the new copy of the project directory

save the new project in the new project directory

 

Only caveat is this will not include any dependencies in your user.lib or inst.lib so the first time you open a vi you might have to find some of the dependencies that are not in default locations.

 

========================
=== Engineer Ambiguously ===
========================
0 Kudos
Message 5 of 22
(15,542 Views)

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

 

 

If those links dont work drill over to my tag cloud for

  • Tag: "ProjectTemplates"

Firefox and my IT dept aren't friendly today

 


"Should be" isn't "Is" -Jay
Message 6 of 22
(15,532 Views)

We made need clarificatioin from the original poster, but I did not think that he wanted a fresh brand new project.  It sounded like to me that he wanted to fork the project some how.  Say he built up a project that worked for project A, and 90% of it was right for project B.  He wanted two projects that were very similar but differed the ways needed to satisfy the requirements of project B.

 

Of course if he wanted a new project LabVIEW has templates and they are great starting points, but many of my projects can benefit from the Actors/Engines already written so I wouldn't want to start at a blank project.

0 Kudos
Message 7 of 22
(15,492 Views)

@Hooovahh wrote:

We made need clarificatioin from the original poster, but I did not think that he wanted a fresh brand new project.  It sounded like to me that he wanted to fork the project some how.  Say he built up a project that worked for project A, and 90% of it was right for project B.  He wanted two projects that were very similar but differed the ways needed to satisfy the requirements of project B.

 

Of course if he wanted a new project LabVIEW has templates and they are great starting points, but many of my projects can benefit from the Actors/Engines already written so I wouldn't want to start at a blank project.


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.


"Should be" isn't "Is" -Jay
0 Kudos
Message 8 of 22
(15,476 Views)

@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.

0 Kudos
Message 9 of 22
(15,471 Views)

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.

Message 10 of 22
(15,453 Views)