LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Is it possible to generate a LVCompare report from the command line?

First, I've read this documentation and seen this thread (from ten years ago). I'm using LV2019 but have the capability to update to 2024. 

 

I'm using BeyondCompare to monitor changes across SVN commits for a large project, and I have configured it to use LVCompare to compare files. The issue is that BeyondCompare can only see that the binary files are different, and then I need to click through each of the (650, today) files that have changed between the two commits. It seems like, especially with the object-oriented VIs, I'm getting a ton of trivial changes, like "VI Icon" when there is no discernable change to the VI icon. I can't just ignore this, though, because there have been some VIs that have changed the terminal configuration, and that is a notable change that does warrant review. 

What I need is a way to have LVCompare generate the report from the command line.

 

I can script BeyondCompare to give me a list of files that are different on a binary basis, and if I could get a command-line mechanism for generating an LVCompare diff report then I could generate one for each file that BeyondCompare says is different and aggregate those reports to filter out things like diffType="VI icon", etc., then I can have BeyondCompare filter the files that aren't flagged as notable. 

0 Kudos
Message 1 of 6
(318 Views)

I haven't tried this method myself, but it looks like there are at least SOME ways to do it:

 

https://lavag.org/topic/20876-hooks-into-lv-compare/

 

I'm not sure if that's exposed in the command line arguments or not, but you could always make a wrapper VI that you call from the command line that does use those command line arguments. It's not exactly what you asked for but maybe it'll get you started.

0 Kudos
Message 2 of 6
(294 Views)

The answer to the question "Is it possible to generate a LVCompare report from the command line?" is "No, but you can write a LabVIEW program that calls LVCompare.exe with the correct parameters and switches.  Just like doing a "Compare" from the Tools menu, it will only compare one VI to another VI, and will show you the differences.

 

I haven't looked at the LVCompare utility for more than a decade.  I found it very useful when embedded in code that compares two versions of a Project to spot which VIs are the same, which are unique to one or the other Project, and which differ.  Note that LVCompare has the same ability to ignore such things as VI Attributes, Front Panel objects' position and size, and "cosmetics" in the Block Diagram.

 

Bob Schor

0 Kudos
Message 3 of 6
(285 Views)

Parameters and switches aside, even if I wrote a VI to call LVCompare, how can that VI trigger LVCompare to generate a report? 

 

But the parameters and switches are limited. How can I ignore icon changes without ignoring all attribute changes, for example? How do I ignore a rename ("data type name" change, which is a functional change on a back panel) without also ignoring add/remove blocks or wiring changes?

 

The reports have a remarkable level of granularity, which is great, but I can't access that level of detail without manually clicking through every VI that has a change, and I don't want to click through 80% of my 650 files that only have icon changes, or "built from different source," or renaming changes. 

 

While I'm on the topic of comparing VIs, it's really annoying that I can't compare two files with the same name. When I'm trying to compare changes on a dynamic dispatch file, one of those files needs to be renamed, which breaks the magic linking between parent class and subclass, so the renamed file's "Call Parent Method" VI breaks, and then that shows up on the comparison as a block diagram change.

 

 

0 Kudos
Message 4 of 6
(246 Views)

@robotics_chuck wrote:

While I'm on the topic of comparing VIs, it's really annoying that I can't compare two files with the same name. When I'm trying to compare changes on a dynamic dispatch file, one of those files needs to be renamed, which breaks the magic linking between parent class and subclass, so the renamed file's "Call Parent Method" VI breaks, and then that shows up on the comparison as a block diagram change.

 


As I recall, I encountered the same frustrations you are facing, especially looking for "needle in the haystack" differences between two versions of a project with multiple folders (about a dozen) and lots of VIs and TypeDefs (at least 800, I think).  Where I had Project 1 and Project 1a with a VI in each with the same name, I'd rename one, run LV compare on the two different (because of the rename) files, and make notes of the differences that I saw.  Tedious and boring.

 

So I wrote a LabVIEW program to help me do this.  It first parsed both top-level folders, Project 1 and Project 1a, parsed all the files of interest (it was more than a decade ago, so all I worried about was VIs (things with the extension .VI) and TypeDefs (extension .ctl).  Once I had the lists, I filtered out the files that were unique to only one TLF (Top Level folder). leaving me with two ordered lists of file paths to compare.

 

Assuming my two "lists of things to compare" can be called "List 1" and "List 2", the processing algorithm went something like this:

  • Rename the current element in List 2 by adding ".tmp" to the file path.
  • Present the two files to compare, <Random VI or Type> and <Random VI or Type.tmp>
  • LVCompare will determine if they are "the same" (based on how you set the options for it).
    • If they same, write the path to <Random VI or Type> to a file called "Same.txt".
    • Otherwise,
      • Write the path to <Random VI or Type> to a file called "Different.txt".
      • Let LVCompare show you the differences between the two.  You may need pencil and paper at this step.  Continue until you are done comparing.
  • Rename the item in List 2 back to <Random VI or Type> (discarding the .tmp added to the extension)
  • Continue until you have compared all of the files, dividing them into those that LVCompare considers the "Same" and "Different", which you've examined.

Note -- if you are following Better Practices and saving your Project to a Version Control System at regular (and short!) intervals, the number of differences should be manageable, with "Same" being much larger than "Different".

 

Bob Schor

0 Kudos
Message 5 of 6
(228 Views)

If you use Git, try the SLL-Toolkit 's Git compare tool that uses lvcompare under the hood and simplifies the diff process across branches. This was presented at GLA Summit 2024 - https://youtu.be/68CuI1XTFeE?si=OF_ceiHt2isw6zYF

Santhosh
Soliton Technologies

New to the forum? Please read community guidelines and how to ask smart questions

Only two ways to appreciate someone who spent their free time to reply/answer your question - give them Kudos or mark their reply as the answer/solution.

Finding it hard to source NI hardware? Try NI Trading Post
0 Kudos
Message 6 of 6
(214 Views)