Malleable Vi Application builder Errors

[HenrikDueholm]

It is not only your problem. I was searching around to see what could cause the error 13 I was seeing. I found this post and your workaround worked for me. Thank you for posting the workaround!

I was also using a 'Stall Data Flow' on an error wire.

This is my error message (note this is from building a packed library):

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

Error 13 occurred at Invoke Node in AB_Engine_Write_Linker_Wrapper.vi->AB_Build.lvclass:Copy_Files.vi->AB_Build.lvclass:Build.vi->AB_PackedLibrary.lvclass:Build.vi->AB_Engine_Build.vi->AB_Build_Invoke.vi->AB_Build_Invoke.vi.ProxyCaller

Possible reason(s):

LabVIEW: Failed to load dynamic library because of missing external symbols or dependencies, or because of an invalid file format.
=========================
Shareable board exclusively owned.

Method Name: Linker:Write Info To File

[wiebe@CARYA]

Could it have something to do with disconnecting type defs when building?

I'd expect the enum to be a type def, but am not sure. Turning the disconnecting off might make a difference.

The Number To Enum.vim seems totally redundant, since the Variant To Data function does a great job. But that would just be a workaround. 

[drjdpowell]

Note: I have identified a quick workaround: remove the "Help path" in the VI properties (Documentation tab) of all VIMs in use:

[wiebe@CARYA]

---

@drjdpowell wrote:

Note: I have identified a quick workaround: remove the "Help path" in the VI properties (Documentation tab) of all VIMs in use:

---

That is unexpected...

[ChrisStrykesAgain · Accepted solution]

After further investigation, we have discovered that this can be caused by using the Fast File Format. This option can be found under the "advanced" section of the Build Properties dialog box. We believe the only way of getting in to this state is by checking the box, which is unchecked by default.

In this case, to avoid Error 13, the box MUST remain UNCHECKED.

Thanks to drjdpowell for the assist.

[HenrikDueholm]

I was looking at my project to see if I was using the 'fast file format'... and I can conclude that I don't really know.

The 'Use fast file format'-option is not an available setting when building PPLs. No other combination of settings in Advanced properties allowed my build to be a success.

[drjdpowell]

PPLs always use Fast File Format, I’m afraid.

[J._Mondry]

I don't think a solution has been found. I Encounter the same application builder problem with a handful of malleable VIs I created. When I put them in a fairly smal test VI and compile the executable, it builds fine. However, when I drop any one of the malleable VIs into an existing large application (just wiring the Input of the malleable VI , not even really using it)the application Fails to build and the usual error message:

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.

I sadly have to stop using malleable VIs completely, since this random behavior endangers application building. I would presume, there is a link between size/complexity of the calling/embedding VI "surrounding" application and the application builder error, some race condition or building Memory conflict ...

Sad, cause I really like the VIM, doing LabView since 3.1(1993 I think) and been waiting for these forever ... sigh!

[J._Mondry]

... To further illuminate this: It's the same with the LabVIEW provided VIMs (sort array e.g.): They do fine in small Projects, I drop one of them into a fairly large application (that builds fine and did so for ages) - 50+ MByte executable - and Application Builder Comes up with the error, Sometimes (no clear correlation obvious) the builder has sucess when Debugging (Keep the code) is switched on at the cost of even bigger executable.

So these VIMs (NI and selfmade) pose a danger for building larger applications and should be avoided! Sad.

[ChrisStrykesAgain]

This should be fixed in 2017 SP1 f1; can you test in that version and confirm?