Got "broken VI cannot save without block diagram" on routine edit of program working for years

[MarkBowles]

I'm maintaining and extending a LabVIEW 2020 program that's has been in production for years. It runs on a cRIO, built on Windows 10, features a custom coded FPGA.

Today I made a series of routine changes, primarily modifying typedefs of a few data structures, and then ironing out the resulting kinks.  No new VIs or controls. No utilization of new external libraries.  I did make a small change to the FPGA and recompiled it using the NI compilation service. I removed a couple network shared variables from the project.

When I built the RT portion, I got:

This complaint is repeatable, including if I shut down and restart LabVIEW.

Anyone have hints that might help me track down this problem?

[MarkBowles]

Workaround: watching the compiler spew out "saving..." messages during the compilation process, I noticed that just before this error appears, it was saving a VI that was no longer called.  I had not removed it from the library because I thought it might come back later, but after removing it from the library, the project compiled successfully.

I don't believe I edited this VI during this last cycle.  That is, it should have been in the exact same condition it was when the project was compiling, before I removed calls to it.

-- m

[billko]

If you're worried about whether it changed or not, you can always revert to the last version that was committed to your repository.

[MarkBowles]

I can open the VI that caused the problem outside the environment of the project.  It opens fine, and contains a complete, apparently unmodified block diagram. 

The offending VI's file system last modification time is around the end of my editing session yesterday -- but since LabVIEW updates source files independent of author edits, this doesn't help much in determining what went wrong.

Inquiring minds want to know:

1) Are there any typical causes of this problem (that I can watch out for in the future)?  What would cause LabVIEW to *think* that a block diagram is missing for a VI when it appears to be intact?  What could I have done to cause this?

2) The error message (frustratingly) does not specify which VI is broken.  My project has over 1,000 VIs and controls.  Is there some way to deterministically find out which VI(s) are affected, without having to get lucky while staring at the compilation "saving..." messages?

Thanks,

-- Mark

[billko]

---

@MarkBowles wrote:

I can open the VI that caused the problem outside the environment of the project.  It opens fine, and contains a complete, apparently unmodified block diagram. 

The offending VI's file system last modification time is around the end of my editing session yesterday -- but since LabVIEW updates source files independent of author edits, this doesn't help much in determining what went wrong.

Inquiring minds want to know:

1) Are there any typical causes of this problem (that I can watch out for in the future)?  What would cause LabVIEW to *think* that a block diagram is missing for a VI when it appears to be intact?  What could I have done to cause this?

2) The error message (frustratingly) does not specify which VI is broken.  My project has over 1,000 VIs and controls.  Is there some way to deterministically find out which VI(s) are affected, without having to get lucky while staring at the compilation "saving..." messages?

Thanks,

-- Mark

---

Wow, that is super-strange.  This VI might be on the verge of corruption.  What I've done in weird cases like this is to make a snippet of the offending code and drop it into a new VI.  Then (with the project closed) rename the original and replace it with the new one.  (Just FYI - but you probably already know this - the snippet should reproduce the front panel as well.)  I think this works because it's not just a copy - the snippet actually rebuilds everything instead.

That's the only thing I can think of.

[altenbach]

In the project menu, have you tried "tools...advanced...clear compiled object cache"?

[*3d0g]

Great thread!

I'll often, as I can, just check in to see if there's some issue that may arise and how it is handled, even if it isn't my issue, today. Great thread, Mark!

[*3d0g]

"The offending VI's file system last modification time is around the end of my editing session yesterday -- but since LabVIEW updates source files independent of author edits, this doesn't help much in determining what went wrong."

Hear! Hear!

an attribute has changed ...my favorite </facetious>

[*3d0g]

"My project has over 1,000 VIs and controls. Is there some way to deterministically find out which VI(s) are affected, without having to get lucky while staring at the compilation "saving..." messages?"

That's why this is a great thread! I am so tuned in!

My project...1000...deterministic...luck

You know what you're doing, for sure. I am sorry I cannot help you, more, but I will bump your thread, Mark, as I see it as very valuable and the least I can do.

[MarkBowles]

Didn't try clearing the compiled object cache.  I'm a long-time C/C++/Java programmer, learned LabVIEW only for this project in 2017.  I'm still a little vague on LabVIEW's support tools, and didn't even know there was a compiled object cache.

I did close the project, made sure LabVIEW was not executing, rebooted the Windows 10 machine hosting the compilation, and retried it -- no change.

Can't try this workaround now, because the problem went away when I removed the unused VI from the project.

So, this cache must be stored in a disk file somewhere in the project, right?  If it were RAM based, the problem would clear up on reboot. And if it were somewhere other than the project, it would get confused when different versions of projects are reloaded from SVN archive.

I am saving the .lvproj file in SVN when I make updates -- am I also saving the cache?