Error message during build

[MartinMcD]

Hello there,

I have some code that was working fine in 2012 but won't build in 2013, I haven't made any changes to the AF code at all.  Has anybody else seen this please?

"A VI broke during the build process from being saved without a block diagram. Either open the build specification to include the block diagram of that VI or enable debugging to include the block diagrams of all VIs in the build. Report this error to National Instruments technical support.

C:\Program Files\National Instruments\LabVIEW 2013\vi.lib\ActorFramework\Actor\Launch Actor.vi"

If I set the build to enable debugging then it does build, but the application is twice the size it was. 

Thanks,

Martin

[tstahl]

I get a similar error in 2012 when trying to compile a packed library containing a child object when the parent is in a different packed library (this is a plugin structure). The way I resolved this was to build the parent object's packed library with enable debugging turned on.

Another thought is if you've tried a binary compile of your code?

[MartinMcD]

Thanks for the reply.  It's funny because I'm not using packed libraries or anything. AFAIK it is just a fresh install of 2013. The error description says:

Click the link below to visit the Application Builder support page. Use the following information as a reference:

Error 1502 occurred at AB_Source_VI.lvclass:Close_Reference.vi -> AB_Build.lvclass:Save.vi

Possible reason(s):

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

[mkabatek]

I dont know if these problems are related, but I had a similar problem with the application builder not working. Please see this thread:

https://decibel.ni.com/content/thread/18244

[fabric]

Not sure about your specific error but I got around some similar issues by unchecking the build option: Additional Exclusions>Modify project library file after removing unused members

[SteenSchmidt]

fabric wrote:

Not sure about your specific error but I got around some similar issues by unchecking the build option: Additional Exclusions>Modify project library file after removing unused members

Just mind that doing the above blindly can be quite a bad practice. It can hide problems with scope configuration and common library segregation (when you have multiple builds that make up your plug-in architecture).

Unchecking 'Remove unused polymorphic VI instances' and 'Remove unused members of project libraries' to resolve a missing component at runtime for instance severely lengthens the build process and bloats the builds unnecessarily. And the underlying problem, that you have some common component that isn't moved sufficiently up top, isn't solved.

One common cause when a build breaks, and you have 'Modify project library file after removing unused members' checked, is that you have some private method inside a library, and the builder modifies by removing the library thus exposing the private methods at build-time. This isn't allowed (it's equivalent to accessing a private method in a public scope), thus your build breaks during the build while everything is fine in the dev-environment. But just unchecking the library modification can cause you to retain too much uneccesary code, where the real problem was scope.

In reality I think there lacks some intelligence in the builder for these situations. For that there is for instance this (very much overlooked idea: http://forums.ni.com/t5/LabVIEW-Idea-Exchange/Make-LVLIBs-work-hassle-free-in-executables/idi-p/2269...).

/Steen

[MartinMcD]

Thanks for the tip, I'm finding that if I deselect 'Modify project library...' it builds fine as well, that is with debugging disabled too.

I'm not sure why I didn't have this problem in 2012 SP1, and I'm confident I'm not doing anything different.

Thanks,

Martin

[fabric]

Steen: Your caution may be sensible but I'm not sure I follow your explanation...

By default, the app builder checks "Remove unused members of project libraries" and "Modify project library file after removing unused menbers" by default. Let's call these "Remove" and "Modify".

The Remove option is simply there to reduce the size of the final build. Assuming the app builder resolves all dependencies correctly this should be pretty safe to do.

The Modify option is a bit more tricky though. My guess is that including the Modify step causes re-evaluation of the dependency tree... and I further guess this *may* add quite a bit of time when building a project with a complex dependency tree. Certainly in my experience it can confuse the app builder enough to invalidate the build... (Would love to post code but in practice I have only observed this on large projects with hundreds of libraries.)

Furthermore, I guess that it is not strictly necessary to perform the Modify step. If unused VIs have been removed, then it doesn't really matter because no other caller will ever attempt to access those VIs... since they are unused!

Anyway, contrary to your suggestion, my understanding is that these options do not in any way remove the libraries themselves. (That would certainly cause problems, particularly with namespace conflicts!)

As always, happy to be corrected on this stuff! 🙂

[SteenSchmidt]

The Remove option is simply there to reduce the size of the final build. Assuming the app builder resolves all dependencies correctly this should be pretty safe to do.

It's safe as long as no one else is going to use that amputated library, which it would then find in memory missing some of its own functions. The app builder can (currently) only take into consideration the dependencies of its current build job.

If you build an exe and a source distribution with plugins, there might be collision between those two dependency trees. Of these we can't let the app builder decide when to strip functions out of the libraries. It simply does not know who else uses that library. Ideally you'd of course create a third (more top-level) source distribution with all common dependencies - this you'd then maintain complete without removing anything, or alternatively you'd carefully prune this top-level dependency lib after careful investigation of all its users. GPower is working on a tool to work out these collisions and split a project into those different dependency packages. It'll be a while yet before we're ready to release it.

The Modify option is a bit more tricky though. My guess is that including the Modify step causes re-evaluation of the dependency tree... and I further guess this *may* add quite a bit of time when building a project with a complex dependency tree. Certainly in my experience it can confuse the app builder enough to invalidate the build... (Would love to post code but in practice I have only observed this on large projects with hundreds of libraries.)

Furthermore, I guess that it is not strictly necessary to perform the Modify step. If unused VIs have been removed, then it doesn't really matter because no other caller will ever attempt to access those VIs... since they are unused!

Anyway, contrary to your suggestion, my understanding is that these options do not in any way remove the libraries themselves. (That would certainly cause problems, particularly with namespace conflicts!)

No, I don't think the library is removed ever, but I'm not certain (the app builder resolves name collisions already when flattening  folder trees, so it could also handle that if necessary).

What I do know is that it for instance will remove a polyVI wrapper and insert the instance VI instead. Consider the case where you have an LVLIB with a polyVI in it. In the LVLIB you then mark the polyVI as public, but the instance VIs inside the polyVI as private (you don't want anybody to call your instance VIs directly). If the Modify option was now to remove the polyVI and replace each of those occurrences in your callers of it with the particular instance VIs, then you'd suddenly have a caller that now calls a private instance VI instead of a public polyVI. And this happens at build time, hence you have a broken VI (your caller of the now private instance VI) at build time but it's not broken at edit time (since then it was calling the public polyVI). Thus exactly the scenario described above.

Cheers,

Steen

[Jeff-P]

Hi Martin,

Glad to hear you have a workaround. Would you be able to send in your code that reproduces the 1502 error to NI? We are interested in reproducing cases of 1502 errors so that we can get CARs filed against application builder. 1502 is a pretty general error that typically indicates an internal error within application builder, so if you are able to send in your code, let me know and I will get a CAR filed so we can try and fix the underlying problem.

Thanks,

Jeff Peacock

Product Support Engineer | LabVIEW R&D | National Instruments