LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

LabVIEW re-saves vi files even though I haven't changed them

Solved!
Go to solution

Hi, all,

 

I am maintaining and enhancing a many-years-old project in LabVIEW 2020, with about 950 vi's and 220 ctl's.

 

My company uses TortoiseSVN for source code management.  I've noticed that I can open the project, make one small change (e.g. the characters in a string constant) and save it, and when I go to close the project, LabVIEW saves another 70 or so vi's.  I've done a little diffing and am of the opinion that the actual binary contents of the files are changing, as well as the last-modified dates.

 

The problem is that the record of what files were actually, meaningfully changed in SVN is overwhelmed with noise when this happens. 

 

I can always reply "don't save" to all those 70 files, but I don't truly know if (a) I might have changed something in one of them and forgotten, or (b) LabVIEW made necessary changes to the files, and if I don't save them, I'll lose something or end up with a consistency.

 

Can someone enlighten me on why LabVIEW does this, and how important it is for me to accept such changes? Is there any way I can keep this from happening?

 

Thanks,

-- Mark

0 Kudos
Message 1 of 3
(173 Views)
Solution
Accepted by topic author MarkBowles

There was a setting introduced around LV 2012(?) that allows you to separate compiled code from the source.  This helps a lot with this issue, as compiled changes don't get saved with the VI.  So if the source didn't change, the file won't change because something in a subVI got changed.  Any new project will inherit this change; old projects you need to update the files.  (The method I believe is in the LV help file for that option.)  On an old project, all your files will get changed one time because you moved all the compiled code from the source to a cache.  After that, you should have a LOT less files that need to be saved.  (And most likely the only files that will show as changed will be the files you actually changed.)

 

There are a few caveats involving an executable calling a VI as a plugin because the runtime needs to have the compiled code in the VI.

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.
Message 2 of 3
(167 Views)

Note that the separation option helps a lot, but not fully. You will still get cases where LV wants to save VIs even though they're separated. Sometimes a revert in memory makes it go away. Sometimes LV insists on it even after closing everything and reopening. Also, note that if LV crashes and restores files, it restores them without the flag set, so if you get restored VIs, you will want to go into them and set the flag again.

 


@MarkBowles wrote:

 

I've done a little diffing and am of the opinion that the actual binary contents of the files are changing, as well as the last-modified dates.

If you're doing a binary diff, you probably want to look at setting LVCompare as your comparison program for LV files (vi, vim, vit, ctl, ctt). This is a program which is included with some versions of LV (I believe pro) and opens a diff dialog in LV. It's far from perfect, but it does help.

 

This is how mine is configured in SVN:

"C:\Program Files (x86)\National Instruments\Shared\LabVIEW Compare\LVCompare.exe" %mine %base -nobdcosm -nobdpos


___________________
Try to take over the world!
Message 3 of 3
(115 Views)