LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

3D graphs are not compiled

Hi-

We have an app in LV2012 where we've replaced some older ActiveX surface maps with the newer Xcontrols. When we build this app, several folders were created in the" \support" folder for all the 3D sub-vi's. When the app started, it wanted those folders in the root, not in \support. Strange. We expected them to link and compile correctly, and not need VIsfor the exe to run. I've browsed the forum a bit but could not find any related issues. Can anyone shed light on this problem?

Thanks, 

Kevin M.

0 Kudos
Message 1 of 8
(2,626 Views)

Kevin,

 

what files do you find in those support directories? Are those only DLLs?

 

There can be some reasons for this:

1.) Additional Exclusions are set incorrect. Test by removing all checkmarks and rebuild the EXE.

2.) You decided to build the EXE using 8.x layout. Because the new 3D graphs use LVOOP (which will most likely use "dynamic dispatching" which requires VI with the same name for several classes) it is possible that the app builder moves those VIs into separate folders. Please uncheck "Use LabVIEW 8.x file layout" in the Advanced tab before building the EXE.

3.) Check if all sources are included in the build. It can be that you require to set graph classes as "Always include" in the Source Files tab. On the Destinations tab and the Source File Settings tab, you can distribute those files into different folders or the EXE itself. Possibly you can find a setting there which will include those files in the EXE (as long as they are LV files like VIs, ctls, ...).

 

hope this helps,

Norbert

Norbert
----------------------------------------------------------------------------------------------------
CEO: What exactly is stopping us from doing this?
Expert: Geometry
Marketing Manager: Just ignore it.
0 Kudos
Message 2 of 8
(2,622 Views)

Hi Norbert-

Thank you for the advice. Our build spec does use 8.x file layout. I will re-build and get back to you.

Thanks again,

Kevin M.

0 Kudos
Message 3 of 8
(2,614 Views)

Hi Norbert-

We made a build after disabling the Labview 8.x file format setting. The 3D controls did seem to compile as expected. Thank you for that advice. However, we call a lot of VIs by reference, so much of our program did not work. Changing that architecture is a daunting task.

 

Do you think "Always including" the 3D control folders would be of any use? Any pointers would be appreciated.

 

Thanks Again,

Kevin M

 

 

0 Kudos
Message 4 of 8
(2,582 Views)

It's worth a shot if you application does not take that much time to compile.

 

 

By calling a lot of VIs by reference, do you mean that they changed where they were in the file heirarchy and that is why they are not found? I found this white paper that goes over calling VIs by reference and while it might not give you an exact "best method" it may give you enough information about how LabVIEW to figure how the best method for your application:

 

http://www.ni.com/white-paper/3929/en

 

-KP

Kurt P
Automated Test Software R&D
0 Kudos
Message 5 of 8
(2,557 Views)

Kevin,

 

i understand that you use VI Server to load and call VIs dynamically which you put into the EXE itself.

The option to build the EXE as "8.x layout" flattens everything i a single folder structure while the 2009 and newer format of the EXE keeps the complete folder hierarchy in your development.

 

Because most often, referencing VIs is done starting with "Current VI Path" and then using build/strip path, the result is different regarding of the build script setting for the EXE.

In order to circumvent this, NI did include a new function in the File Constants palette which is called "Application Directory". I recommend you to use this function instead of "Current VI Path". Please refer to the help of this function for a detailed information on the functionality.

 

hope this helps,

Norbert

Norbert
----------------------------------------------------------------------------------------------------
CEO: What exactly is stopping us from doing this?
Expert: Geometry
Marketing Manager: Just ignore it.
0 Kudos
Message 6 of 8
(2,546 Views)

Norbert-

Thank you for the explanation of the different file structures. We've used use that primitive quite a bit- a mere 150 instances or so.
I'll  look into making the changes and firing off another build. Will keep you posted.

Thanks again for your ongoing assistance.

Kevin

 

0 Kudos
Message 7 of 8
(2,536 Views)

Update (finally)

In our initial solution, we used static vi references to make dynamic calls. This worked, but significantly increased the size of our executable.

We  then added code to fabricate vi paths,  and removed the static references. The executable size returned to normal, dynamic vi’s opened cirrectly in our 32-bit app. However, when we tried building the same project in 64-bit, the calls to dynamic vi’s threw errors. 

 

 Diagnostic code showed that the paths in the 32-bit app were relative to the exe. If my dynamic vi is at this path:

“C:/local depot/ Product_A/MyApp.vi/Source Code Folder/MyDynamicSub.vi,

the internal path is MyApp.exe/Source Code Folder/MyDynamicSub.vi

 

 

In the 64-bit exe, the path was nearly absolute (it omitted the drive letter).  In our folder structure, the path included two levels above the exe:

MyApp_X64.exe/local depot/Product_ A /Source Code Folder/MyDynamicSub.vi.

So for now, we are using static vi refs in the 64 bit build.

 

The xml tags in the Project file are different.

The 32 bit uses :

<Property Name="Destination[0].destName" Type="Str">MyApp.exe</Property>

<Property Name="Destination[0].path" Type="Path">../Build/NI_AB_PROJECTNAME.exe</Property>

<Property Name="Destination[0].path.type" Type="Str">relativeToProject</Property>

<Property Name="Destination[0].preserveHierarchy" Type="Bool">true</Property>

 

 

In 64 bit:

<Property Name="Destination[0].destName" Type="Str">MyApp_x64.exe</Property>

<Property Name="Destination[0].path" Type="Path">../Build/ MyApp _x64.exe</Property>

<Property Name="Destination[0].path.type" Type="Str">relativeToProject</Property>

<Property Name="Destination[0].preserveHierarchy" Type="Bool">true</Property>

 

I tried using the  32 bit tag (NI_AB_PROJECTNAME.exe) in the 64 bit section, but did not get lucky.

 

Thanks,

Kevin

0 Kudos
Message 8 of 8
(2,483 Views)