06-27-2017 08:50 AM - last edited on 07-07-2017 02:25 PM by karina.barles
Dear Community
We were starting using LV2017 and started to use the very nice melleable vi's.
I have found a big problem when using some melleable vi's from the palette and the build an application using the application builder.
In the context of my project i get the following error message when i use the part of the code shown below.
Full message is this:
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_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: 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
Code generating the above error:
Working Code:
I also used the "Number To Enum.vim" from the palette within a different context which lead to the same error.
Please can somebody state if this is only my problem or commonly known ?
Thank you
Solved! Go to Solution.
07-03-2017 10:00 AM - edited 07-03-2017 10:04 AM
Hi Gernot,
can you post your code? I tried with a very basic VI and it worked without problems, also the building of the Exe. Attached is my code, that was successful in building an exe.
Can you show the wire under your disabled/enabled structure? Only if there was some strange behavior in there....
Cheers, Niko
07-04-2017 02:03 AM
Dear Nico
Thank you for the response.
The main problem is that this behaviour only happens in the context of two big projects where I am currently not able to seperate the code in a way that it is postable.
Too many dependencies and even special external hardware requirements to run properly.
I go on vacation next week.
I will try to shrink my code to a minimum to post it including the problem after my vacation.
As I use the workaround currently it is not to urgent.
07-04-2017 02:08 AM
Dear Gernot,
good that you have a workaround in the mean time. Let me know if you can reproduce the error with my code snippet or you can shrink down your code to a minimum size so I can test it on my side.
Cheers,
Niko
07-07-2017 12:40 PM
When I added the following to my VI, it would not build correctly. I am using other malleable VIs, including home-brewed ones, and it does build correctly. Once the malleable VI below was removed, the VI built correctly into an exe.
mcduff
07-10-2017 11:29 AM
Here's another VIM that caused the same problem.
Interestingly, when I converted it to a "real VI", the problem did NOT disappear and the same error occurred.
mcduff
08-21-2017 04:34 AM
Has NI worked on this? I am experiencing a similar error in building in 2017, though I haven't narrowed down the source yet (but I have started to use VIMs).
Error 13 occurred at Invoke Node in AB_Engine_Write_Linker_Wrapper.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_Build.lvclass:Build_from_Wizard.vi->AB_UI_Frmwk_Build.lvclass:Build.vi->AB_UI_FRAMEWORK.vi->AB_Item_OnDoProperties.vi->AB_Item_OnDoProperties.vi.ProxyCaller
08-21-2017 05:20 AM
Issue traced to the "Is Value Changed.vim" Malleable VI. Confusingly, though, I have another VI that call this VIM that CAN be built without error. Also, simple VIs made to try and reproduce the issue build fine. So there must be an interaction between the VIM and some other feature of the VI being built.
08-21-2017 06:58 AM
Made my own "On Change" VIM, that has the same internal code as "Is Value Changed?" but was made from scratch. Using this doesn't seem to cause a problem.
08-22-2017 02:42 AM
Sometime if you e.g. drop property nodes that break the code the error is pointed out at a completely different place, i guess some error propagates in the wrong order. Could this be something similar?
/Y