LabVIEW Idea Exchange

About LabVIEW Idea Exchange

Have a LabVIEW Idea?

  1. Browse by label or search in the LabVIEW Idea Exchange to see if your idea has previously been submitted. If your idea exists be sure to vote for the idea by giving it kudos to indicate your approval!
  2. If your idea has not been submitted click Post New Idea to submit a product idea to the LabVIEW Idea Exchange. Be sure to submit a separate post for each idea.
  3. Watch as the community gives your idea kudos and adds their input.
  4. As NI R&D considers the idea, they will change the idea status.
  5. Give kudos to other ideas that you would like to see in a future version of LabVIEW!
Showing results for 
Search instead for 
Did you mean: 

Option for LVCompare to ignore VI Version differences

Status: Declined

Any idea that has received less than 2 kudos within 2 years after posting will be automatically declined.

We have a rather large code repository and are currently making a step-by-step switch to a newer LabVIEW version.  Many of the VIs in question are used on Real-Time targets.  These are automatically saved whenever deploying.  Until now I have been using a tool of mine to parse entire directories of files and compare them to base versions in our SVN repository, automatically reverting those with no "real" changes.  We have branches open in both the old LV version and the new LV version in order to maintain bugfixes for customers unable or unwilling to upgrade their LV version.


I can choose to ignore FP cosmetics, BD cosmetics and so on but what I cannot ignore is LV Version.  I now have a situation where I need to commit upwards of 300 VI files where the vast majority of them are unchanged except for saving in the new LabVIEW version or manually sift through lots of VIs in order to retain these VIs in their original version.


I would love to have an option to allow LVCompare ignore this kind of change so that we can easily automate this kind of operation.

One issue that I might see with this is that while the block diagram might have changed, the actual underlying code might be changed due to changes in the compiler. So, while it appears that only the LabVIEW version has changed, actually far more has changed then appears.
Jon D
Certified LabVIEW Developer.
Proven Zealot

This is a non-issue as "VI Version" will then no longer be the only change.....  The other changes will still register.

Proven Zealot
Status changed to: Declined

Any idea that has received less than 2 kudos within 2 years after posting will be automatically declined.

DNatt, NI

I'd like to give this idea Kudos and therefore get it over the <1  Kudos threshold.

The whole concept of LabVIEW insisting on a completely new LabVIEW install each year, with all vis having to be upgraded (and therefore incompatible with older versions of LabVIEW) creates numerous configuration control issues.


I have a project which I have made a minor change to one file in, and needs code reviewing by a colleague. However, to build for a newer FPGA target we are now utilising, I had to upgrade to LabVIEW 2017. Now 100s of files are shown in SVN as having been modified and each file needs checking to confirm only the version has been modified. If there was a switch in LVCompare to ignore version change, it would then just show the one or 2 files that have been changed.


This most definitely isn't a "non-issue".