LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

error 1052

I'm trying to build an application where some VIs are using subVIs that are in a llb (HP6XXX.llb in the instr.lib folder) probably causing the error 1052. Is there a workaround to solve this, I looked at the different posts referring to this error but didn't find anything that may solve the issue in my case. I'm thinking at creating a library in my project, copy the .llb VIs that are used in it and replace the .llb VIs by the ones in the project library. But there might be a simpler solution.

 

Unrelated to this error: My main application is calling VIs in a subpanel when specific buttons are pressed (e.g. whe "TEST A" button is pressed the TEST A VI load and run in the subpanel). When I create the build should all these VIs be converted to .exe prior to the build (I don't know if an executable can be loaded in a subpanel)? What would be the good approach to create the build?

 

Sorry I can't post the code.

 

Thanks

 

Ben64

0 Kudos
Message 1 of 7
(3,586 Views)

Not sure of the first part, don't know what an error 1052 while building an application, but you don't need to make the "plug-in" vi's into exe's, they can remain vi's. If you want to protect your IP (intellectual property) or prevent editing (assuming that there was the development version of LabVIEW on the target machine, which isn't necessary with .exe) you could save the plug-in vi's without diagrams. Just make sure that they are saved to another location than the original development one, and/or that you have backup copies, because once saved without diagrams they can no longer be edited.

Putnam
Certified LabVIEW Developer

Senior Test Engineer North Shore Technology, Inc.
Currently using LV 2012-LabVIEW 2018, RT8.5


LabVIEW Champion



Message 2 of 7
(3,582 Views)

The 1052 error is probably being caused by illegal characters in the names of the VIs inside the LLB. The names of the VIs inside the LLB are "protected" from normal filename rules. However, when you build an application this no longer holds. There's probably a VI in there that has a "/" character or something similar. To fix this you have to rename the VI in the LLB to use valid characters for the name per your OS filesytem rules.

 

For the plug-ins these are called dynamically, so they should be included in the list of dynamic VIs in the source files section of the application build properties.

Message 3 of 7
(3,571 Views)

Thanks smercurio, there were some vis in the llb with name containing the / character. By changing the name I was able to build the application. I'm now facing another challenge, having the application work! I attached a picture of the project tree.

 

I added the plugin vis (the VIs in the integration folder) in the dynamic VI list but the problem is these VIs are using .ini files (located in the Support Files folder) and subVI that are in a lvlib (RCM PDU.lvlib). When I run the .exe I get the error message shown in the attachment. Note That the plugin vis use relative path to the .ini files which might also need some tweeking.

 

I'm still not sure what is the best approach. When I create an installer and add the integration folder in the program file directory the plugin vis loads and the .ini files are found but the plugin vis subvis that are inside the lvlib are not.

 

Ben64 

Download All
0 Kudos
Message 4 of 7
(3,559 Views)

The error message indicates that the VIs aren't in the executable. This can happen if the VIs are only reference via a dynamic VI. When you build the application it can only load those VIs that are directly referenced from the top-level VI. If you have subVIs that are in the project but are only used by the plug-ins then these need to be added as support VIs to ensure they get included into the executable.

0 Kudos
Message 5 of 7
(3,545 Views)

I've been trying to include these subVIs into the executable but I still get an error 7. I don't know how LabVIEW deal with the plugin VIs when the

executable is built. In the IDE the plugin VIs are called using relative path from the main VI. Does this need to be modified if the plugin VIs are

included in the executable?


Also, the plugin VIs share some subVIs whit the main VI. These VIs are in a project library. When I try to add this library in the installer I get the following error message: "The LabVIEW project library does not share a common path to disk with the files the project library owns."

I'm still trying different combinations/options of builds but so far haven't succeeded.

 

Ben64

0 Kudos
Message 6 of 7
(3,530 Views)

Got it!

 

The way to go is effectively to add the plugin VIs in the executable. The issue was that some of the plugin VIs subVIs were not found in the build. I found part of the answer in this thread. When creating the executable I need to check the "Use LabVIEW 8.x file layout" because some of the subVIs are in a .lvlib. Still it would be interesting to hear from an NI Application Engineer how to deal with the issue with LV2009/2010 file layout.

 

Second part of the fix was to modify the relative path of some .ini file to point to the data folder created with the executable.

 

Thanks to all.

 

Ben64

0 Kudos
Message 7 of 7
(3,525 Views)