error : Cannot save a bad VI without its block diagram.

[Chris_in_Colorado]

"Cannot save a bad VI without its block diagram."

"could not load front panel"

Google search couldn't find the answer to my problem, so I'll post it here.

I was seeing the above messages during application build.

The problem was I had created an XML library of VIs, but later renamed a file in the folders manually.

Looking at the XML library list, it showed the old filename. I deleted it.  And then added the new file using "add".

Hope this helps someone.

[Jon_S.]

What exactly are you trying to build with App Builder...an exe, dll?  If you are trying to create an exe see if you can build it with debugging enabled.  Also, make sure you include the front panel and block diagram of the VI in question.

[ChuckDiesel]

I don't know if this issue was solved by the OP, but I am having the same issue now.

When building an EXE application for release (without debug), I get the following message:

An error occurred while saving the following file:

C:\Program Files (x86)\National Instruments\LabVIEW 2012\vi.lib\ActorFramework\Actor\Launch Actor.vi



Visit the Request Support page at ni.com/ask to learn more about resolving this problem. Use the following information as a reference:

Error 1502 occurred at AB_Source_VI.lvclass:Close_Reference.vi -> AB_Build.lvclass:Save.vi -> AB_Build.lvclass:Copy_Files.vi -> AB_Application.lvclass:Copy_Files.vi -> AB_EXE.lvclass:Copy_Files.vi -> AB_Build.lvclass:Build.vi -> AB_Application.lvclass:Build.vi -> AB_EXE.lvclass:Build.vi -> AB_Engine_Build.vi -> AB_Build_Invoke.vi -> AB_Build_Invoke.vi.ProxyCaller

Possible reason(s):

LabVIEW:  Cannot save a bad VI without its block diagram.

I have tried recompiling and saving to no avail. Even tried repairing the LabVIEW installation through the programs manager. The Launch Actor.vi that it's complaining about has no errors and I am able to view the block diagram.

The issue goes away if I build the EXE with debugging. Will that slow down my program though? What's going on here?

Using LabVIEW 2012 SP1 32bit on Windows 7 64 bit.

Thanks

[mikeporter]

How many places is that VI called? Can you open them and view their BDs without problems?

Mike...

[ChuckDiesel]

It's called 15 times across 6 VIs. In all places it opens correctly, and I have tried recompiling all VIs numerous times.

[ChuckDiesel]

I was able to solve the issue by installing LabVIEW 2013; it appears the underlying issue was a corrupted default class data instance that wasn't being updated to a compatible version. Updating to my LV2013 only brought the issue to LV's attention. Warning I received upon loading the project in LV2013:

    LabVIEW:  Attempted to read flattened data of a LabVIEW class. The data was written by an old version of the class and the class in memory no longer supports loading and mutating data from that older version. LabVIEW class Actor Framework.lvlib:Actor.lvclass supports versions 1.0.0.3 through 1.0.0.4. The flattened data is in version 1.0.0.1. Your control or constant value has been reset to the class default value.

The preceeding warning came up in 3 places.

Chuck

[mpliax]

Sorry if this an old thread, but maybe what I encountered might help somebody:

I had the exact same error (which enabling debugging solved temporarily) and was solved permanently when I removed an error indicator from a VI. 

Inside the VI I had some custom error codes which popped up an error message. However, deleting the error out indicator solved this. I have no idea why this happened, but this solved it.

[billko]

---

@mpliax wrote:

Sorry if this an old thread, but maybe what I encountered might help somebody:

I had the exact same error (which enabling debugging solved temporarily) and was solved permanently when I removed an error indicator from a VI. 

Inside the VI I had some custom error codes which popped up an error message. However, deleting the error out indicator solved this. I have no idea why this happened, but this solved it.

---

Are you SURE it solved it, or is it just not reporting the error any more?  It's like solving your car alarm going off by cutting the wires from the alarm to the horn.  It's still going off, you just can't hear it any more.

[mpliax]

@billko wrote:

---

---

Are you SURE it solved it, or is it just not reporting the error any more?  It's like solving your car alarm going off by cutting the wires from the alarm to the horn.  It's still going off, you just can't hear it any more.

---

Does the existence of error indicators influence the output/result of the build? I mean, is it possible that the fact that I deleted it "forces" the compiler to build it in some other way? I'm always referring to the building of an .exe, not just running it. I can run it either way, I just couldn't build it in an executable.

[billko]

---

@mpliax wrote:

@billko wrote:

---

---

Are you SURE it solved it, or is it just not reporting the error any more?  It's like solving your car alarm going off by cutting the wires from the alarm to the horn.  It's still going off, you just can't hear it any more.

---

Does the existence of error indicators influence the output/result of the build? I mean, is it possible that the fact that I deleted it "forces" the compiler to build it in some other way? I'm always referring to the building of an .exe, not just running it. I can run it either way, I just couldn't build it in an executable.

---

I was thinking this was happening at runtime.  Sorry that I was an idiot about that.  In fact, I've had a few similar instances where something unrelated to the build (or so I thought) made the app builder cough up a hairball.  The elimination of an error indicator does still scare me a little, though.