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

[tst]

---

@MarkBowles wrote:

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?

---

No to both. LV started life as an interpreted language, but changed to being compiled relatively early on (I believe at version 2, around 1989). The compiler analyzes the changes you make and recompiles VIs as you edit based on those changes.

Originally, each VI file would include both the source code and the compiled code inside it. In LV 2010, NI added the option to save the compiled code separately from the VI file, which has a number of advantages (and this compiled code is stored in that cache). This doesn't apply to all VIs at all times (for example, I believe VIs with express VIs inside them still don't support this and when you build an EXE, the compiled code is included in the VIs which are saved inside the EXE and there was/is a bug where recovering VIs after a crash would cause the flag not to be set on them), but it should apply to most by default.

The actual cache is an SQLite DB and can be stored in more than one place. For code that you work on, the cache is stored in %Documents%\LabVIEW Data\VIObjCache. There's also a separate cache which is installed inside the LV folder, and I believe includes the code that ships with LV, as well as other things which are installed under the LV folder. The cache includes the path to each VI and the last modification date and size so that LV can quickly check if the VI needs to be recompiled.

All this means that when you update to a different version in SVN or open the project in another version or in another computer, the VIs which are set to have separate compiled code will automatically recompile and update the cache if needed.

[IlluminatedG]

This error tends to come around from code in diagram disable structures that change what code gets included once compiling for run-time context. Did that VI have any conditional disable structures that could change what gets built into the app at all?

This error means that the builder already handled a VI which includes stripping the block diagram source but then ran into another dependency that caused it to need to revisit that VI but now it can't do anything with it because the BD is already gone.

Some class hierarchy stuff can cause this as well especially when included in disable structures which means there'll be different DD options between source and build since even in edit mode, code in disabled diagrams still factors into linker info and dependencies.

[MarkBowles]

---

@IlluminatedG wrote:

This error tends to come around from code in diagram disable structures that change what code gets included once compiling for run-time context. Did that VI have any conditional disable structures that could change what gets built into the app at all?

---

Here's the VI (opened independent of the project) that caused the issue:

This purpose of the edit was eliminating a Deuterium control, so the two Deuterium NSVs that it set to TRUE were removed from the project.  The value "Deuterium Press Control" in the enum typedef was also removed, which is why the constant shows up greyed in this view.  There are other VIs similar to this one, that set "Hydrogen Valve" or "Helium Valve" TRUE, that stayed in the project.

[Shuggy1]

I have intermitently had exactly the same problem from a VI that i have not edited for the last 2 weeks. I reboot, restart of labview or a 5 min rest has resolved it until now but i don't like it's randomness! I will try some of the above.

[MarkBowles]

This happened to me again today with the same program, same development envionment.

Clearing the compiled cache did not help.

I was doing a bit of a "slash and burn" edit, in which I reorganized a bunch of data structures, relying on compiler errors to find the field names that were no longer valid.  After some investigation, I discovered that this error came up on VIs that actually had compiler errors -- but the system didn't flag them as such, and instead fell over with this strange "no block diagram" error.

So, if you get this error, go back through the VIs that utilize structures you have recently changed, and check that they really do compile.