Error 1502 when building an application

[BillMe]

I get the following error when building my AF project:

Any help would be appreciated.

[Oli_Wachno]

Have you made any changes to the AF code situated in vilib?

Have you tried a mass compile of the AF?

Just as first thoughts...

[BillMe]

I've made no changes to anything in vi.lib. I can open the referenced file and it is not broken. I'll try a mass-compile.

[mthimm1]

Did you look, if the block diagram of "Init from Existing Queue" is included in your build specification?

By default in my opinion all block diagrams are included. In the Advanced category you can also create a build protocol.

[BillMe]

Oops, under Advanced Exclusions: Disconnect Type Definitions and Remove Unused Members of Project Libraries were checked (I normally have those unchecked). Unchecked and no more error 1502.

[Jolt]

Just ran into this myself. For my situation, the solutions suggested in http://digital.ni.com/public.nsf/allkb/8683D4C66F5CA50E86257341007CF34D didn't help.

Also, the file identified by the build error was not the issue (in my case "Actor.vi").

It turns out that there was one of my VIs that had error but the error was not recognized by the IDE compiler or through a mass-compile operation. I found it by "Save As >> Duplicate hierarchy to new location" on my startup VI - opening this in a new project showed me the offending VI.

In this case it was a accessor property node that I had made which was no longer valid (but again, not caught by the compiler).

I went back to my original project, fixed there error in that VI and everything worked OK.

On a side note I have found the property node accessors created from classes to be flaky in other ways. I now try to avoid them but don't know if this is really "best practice" - any thoughts out there?

[MKIT86]

I recently had the same issue with error code 1502 on "Init from Existing Queue.vi" as in the first post.

The AF library itself is not broken, because this build error 1502 only occurs in one of my AF projects, the others can be built without an error.

However, disabling the "remove unused members of project libraries" as suggested does not work for me, since I am using quite a lot of third party instrument drivers and the "VI tree.vi" will cause a broken build. I don't want to change external libraries just to build this one (corrupted?) project.

But anyway, I found out that it is still enough to disable the "modify project library file after removing unused members" to get rid of the build error.

Even though this works as a workaround, I am still not quite sure if I like it. It feels like a cheap fix and I would like all of my projects to compile with the same compiler settings.

Maybe I have to test the ideas from Jolt (Save As..), but this seems to be a lot of work. I am using a self-build framework on top of the actor framework and most of my projects contain a lot of libraries which all have to be "saved as" separately?

The debugger indeed does not find the corrupted VI, and I tried to find the bug by myself by looking into all subVIs, but couldn't resolve it.