LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Opening LabVIEW project modifies VI

The dirty do does indeed appear.  But, I don't even have to open up that particular VI for labview to ask to save the changes.  Merely opening a vi inside the containing project causes this 'save changes' message.  

 

If I discard the changes GIT (my source code control) will not show any changes.  

0 Kudos
Message 11 of 23
(2,210 Views)

Has anyone found an fix for that? a have a project that contains a couple thousand VIs, but only 3 particular VIs would get labeled as "changed" every time just from opening  *.lvproj file after a version control checkout (using "pull" with tortoiseGit). The code is separated, labview install is the same on all machines, etc., etc...

The change details are: "The VI's name was changed outside of LabVIEW, or one of its subVIs was found in a different directory."

0 Kudos
Message 12 of 23
(1,818 Views)

I did some experimenting  - opened project after a fresh pull - when I close it,I get a message that the same 3 VIs are modified, together with project file. I then created a VI inspector (attached). When I run the inspector once for any of the offending VIs,I get 0x8000000000000000 in the Modifications:VI Modifications Bitset. When I run it second time, Modifications Bitset is 0. The offending VI file  attributes are not changed and there're no modifications reported by tortoiseGit. Opening project now does not prompt to save any of those 3 VIs now. It seems to me that the false changes are related to re-compiled code heap.

Message 13 of 23
(1,814 Views)

Some more experimenting - after experimenting with 64-bit LV, I switched to 32-bit, where I found that the offending VIs would still trigger "save changes". Repeating the above process would clear that,making even a stronger case for separated compile  code heap issue,since 32 and 64 LV clients's keep separate compiled code heaps.

0 Kudos
Message 14 of 23
(1,812 Views)

Update:

I've since upgraded to LV 2018 - the bug is still there.

 

I also tried un-checking and re-checking "separate compiled code..."  various permutations  between several development machines in hopes of resetting the corrupt complied heap, to no avail.

 

Is this problem even on NI radars?

0 Kudos
Message 15 of 23
(1,747 Views)

Update:

I tried to use compare tool to trace the problem and it seem to point to modification to VI icon(?!). Really odd.

Updating icon does not seems to fix it though.

0 Kudos
Message 16 of 23
(1,724 Views)

I've also seen this on occasion with TortoiseSVN.  It most often happens when I do a Commit or an Update "between machines" (i.e. I Commit on my Desktop at work, then Update on my Laptop at home).  If it is only happening on <1% of your VIs, I'd downgrade this to a "minor annoyance" ...

 

Bob Schor

0 Kudos
Message 17 of 23
(1,721 Views)

I'd agree that it is a minor annoyance.  I use GIT for source code control and there are just a few vi's that consistently have 'changes' to be saved.  Never was able to track down what is different between the code on each machine.

0 Kudos
Message 18 of 23
(1,714 Views)

This thread has been quiet for a couple of years, but it comes the closest to anything I have found with this issue.  I have 2 machines and use GIT/TortoiseGit to pass code between them (and some other developers).  There are many files in the project but only one of them has this same issue described n this thread, It is always modified the first time the project is opened then closed after a pull.

 

I used the inspector.vi program on it, opening and closing only the project and not the vi and here is what I found (This is different from other vis which never change):

 

1: After a pull and before opening the project: 

Execution State = 0

Contains Compiled Code = false

Metrics: Block diagram loaded = true

Modifications: VI Modifications Bitset = 0

Modifications: Front Panel Mods Bitset = 0

Modifications:Block Diagram Mods Bitset = 0

 

2: When the project is loaded (no vi's have been opened)

Execution State = 0

Contains Compiled Code = false

Metrics: Block diagram loaded = true

Modifications: VI Modifications Bitset = 200

Modifications: Front Panel Mods Bitset = 0

Modifications:Block Diagram Mods Bitset = 0

 

3. After the project has been closed (and the vi has been saved)

Execution State = 0

Contains Compiled Code = false

Metrics: Block diagram loaded = false

Modifications: VI Modifications Bitset = 0

Modifications: Front Panel Mods Bitset = 0

Modifications:Block Diagram Mods Bitset = 0

 

Other .vi's I have inspected are unchanged throughout the process:

Execution State = 0

Contains Compiled Code = false

Metrics: Block diagram loaded = false

Modifications: VI Modifications Bitset = 0

Modifications: Front Panel Mods Bitset = 0

Modifications:Block Diagram Mods Bitset = 0

 

 

0 Kudos
Message 19 of 23
(1,421 Views)

POSSIBLE SOLUTION (for my case at least), this may not apply to other cases.

 

Kudu's to Fedor for the inspector.vi program.

 

Thanks to a colleague who figured out the where the offending code was by removing code sections until he found the section that was causing Modifications: VI Modifications Bitset = 200.

 

Some details of my particular case:

The offending VI was a class override from one class.  A property of the original class is an instance of a  different class. Inside the VI, is a cast to more specific class, a class control used as the type input to the cast (of the property class), and an accessor from the property class.  There was more in the VI also.  I moved the cast, etc to another vi (which also needed to be an override of the original class) and now the issue stops happening.

 

May not work for your case but the point seems to be it has something to do with the combination of code and subvis within it. Using Fedor's inspector.vi look out for the Modifications: VI Modifications Bitset.  Note that the Metrics: Block diagram loaded still has the same behavior as from the earlier post.

 

0 Kudos
Message 20 of 23
(1,409 Views)