LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Anyone experiencing frustration moving files between LabVIEW Projects, Libraries, and Classes?

Who in their right mind decided to embed all these crazy cross-references INSIDE of the source files?  What a horrible decision...  How could anyone screw this up so bad?

 

https://knowledge.ni.com/KnowledgeArticleDetails?id=kA00Z0000019QoTSAU&l=en-US

 

Solution

We do not have a way to automatically merge two LabVIEW projects. To merge them, you can copy files and other project items from one project to the other.

 

You're joking right?

 

0 Kudos
Message 1 of 11
(802 Views)

Hi motsa,

 

what is your problem and what is your use case?

Best regards,
GerdW


using LV2016/2019/2021 on Win10/11+cRIO
0 Kudos
Message 2 of 11
(785 Views)

For starters this

LotsaMotsa_0-1669929196576.png

 

I would just like to simply copy a source code from one directory to another.  Without having cross-references attached to the source file.

 

 

0 Kudos
Message 3 of 11
(781 Views)

Hi motsa,

 


@LotsaMotsa wrote:

For starters this

 

I would just like to simply copy a source code from one directory to another.  Without having cross-references attached to the source file.


So you show a VI in a text editor: what do you want to see here?

 

What's your problem with copying a VI to a different folder?

 


@LotsaMotsa wrote:

I've actually used LabVIEW for quite a while and have never found a clean way to transfer files and merge files between different projects.


Which kind of files do you want to "merge"?

Why do you need to transfer files to different projects at all? Why not use the same file in two or more projects?

 

Again: what is your use case? I don't understand your problem...

Best regards,
GerdW


using LV2016/2019/2021 on Win10/11+cRIO
0 Kudos
Message 4 of 11
(757 Views)

My issue is with the knowledge-base article. 

 

I've actually used LabVIEW for quite a while and have never found a clean way to transfer files and merge files between different projects.  The method NI suggested does not work. 

 

Have you or anyone at NI actually tried what the knowledge base article suggested?  That never works.  "You can copy files and other project items from one project to the other."

 

The other issue and gripe is that the user can't just look in the source code and figure out what is going on, which is really the way it should be.  That's why I posted the source code.  Sort of as a joke.

0 Kudos
Message 5 of 11
(750 Views)

Hi motsa,

 


@LotsaMotsa wrote:

Have you or anyone at NI actually tried what the knowledge base article suggested?  That never works.  "You can copy files and other project items from one project to the other." 


I do that very often, without any problems.

Right now it is a design decision in our team to copy files from our reuse library into the project folder to keep "complete" projects in our repositories...

 

Why should a user see source code at all? A user should get an executable! 

Best regards,
GerdW


using LV2016/2019/2021 on Win10/11+cRIO
0 Kudos
Message 6 of 11
(729 Views)

If you copy a VI from one project to another, all of the dependencies of that VI gets copied into the new project as well.  Those dependencies get thrown into "dependencies" inside the new project.

 

Copying from one project to another is not that simple.  The file the user copies brings with it a lot of other dependencies that the user is left to sort out.  In many cases, those dependencies still have ties to the old project.  This can lead to a lot of confusion.

 

Can you explain how you copy from one project to another without cross-references between the two projects?  The dependency files in the old project are still likely in the old project directory rather than the new project directory where the user might like them to be.  I have run into multiple cases now where these dependencies cause projects and project files to break.

0 Kudos
Message 7 of 11
(709 Views)

The easiest way to "break" from dependencies on the old project is to physically copy the file, then delete the old project folder (or rename it something else).  Then add that file to your new project.  That way you may wind up with a broken VI, but you won't end up with crosslinked files.  If your new project has the same dependencies, your copied file may even pick them up automatically.

 

Really, though - if you're copying files between projects, that makes a good case for putting those files in their own library as a dependency.

Bill
CLD
(Mid-Level minion.)
My support system ensures that I don't look totally incompetent.
Proud to say that I've progressed beyond knowing just enough to be dangerous. I now know enough to know that I have no clue about anything at all.
Humble author of the CLAD Nugget.
0 Kudos
Message 8 of 11
(643 Views)

@LotsaMotsa wrote:

If you copy a VI from one project to another, all of the dependencies of that VI gets copied into the new project as well.  Those dependencies get thrown into "dependencies" inside the new project.

 

Copying from one project to another is not that simple.  The file the user copies brings with it a lot of other dependencies that the user is left to sort out.  In many cases, those dependencies still have ties to the old project.  This can lead to a lot of confusion.

 

Can you explain how you copy from one project to another without cross-references between the two projects?  The dependency files in the old project are still likely in the old project directory rather than the new project directory where the user might like them to be.  I have run into multiple cases now where these dependencies cause projects and project files to break.


No, when you copy a VI, its dependencies are NOT copied. The dependencies remain the same, and the dependencies are listed under dependencies. 

 

If you don't want dependencies to be "copied", then don't HAVE dependencies to the old project in the VI you are copying. Create reuse-libraries for code that is shared between projects and both projects will instead list that as dependencies. Don't let a project link to another project's code if it is not a reuse-code-project . Having duplicates of code is bad design. But if you are after having full control of which version of these reuse/common VIs that you want per project, then I recommend to use SCC submodules (Git) for reuse libraries.

 

I have never even had the thought "I need to merge these two projects". If you have structured your code libraries, you will never have to.

Certified LabVIEW Architect
Message 9 of 11
(600 Views)

If you want to reuse source code reuse it!  The "source" belongs in a Library inside a project with its Unit Tests, Documentation, private dependencies and Public API and Examples (custom errors, mnu files etc...)

 

Then reuse it! Don't fork your source inside the new project!  If you need a Library modification, tag the old version and create an updated one running the regression tests and updating the requirements document for the changes required in version X++.


"Should be" isn't "Is" -Jay
0 Kudos
Message 10 of 11
(583 Views)