LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

How to include properly OpenG and Unicode into the executable.

I was hopeful but unfortunately it didn't work. 

I am running the SW on another bench now, but this is the same issue with the executable.

0 Kudos
Message 11 of 16
(923 Views)

When I started building Executables (which I don't do that often, so I tend to "forget the messy details"), I remember reading something about the Path being subtly different for code being run in "Development" mode, and code being run in "Run Time" mode.  But I also learned a method for (more-or-less) "programming around" this difference, which I built into a sub-VI that I just automatically carry around with me because I know "it works".

 

     Here's the idea:  When you build an Executable, there is a Category called "Destinations" that lets you define a "Support Directory", which (by default) is called "data" and lives one level down from the folder that contains the Executable (the .exe) itself.  When I create my LabVIEW Project, I keep it and pretty much all of the Project-unique files (or everything not already in a Library, such as OpenG) in a Folder (usually with sub-folders for TypeDefs, Documentation, and Resources).  I also create a Data folder inside the Project Folder, which is where I put all of the files (including .ini and other "Configuration" files, the Error Log for this Project, and the "output" files, the files that hold the results of running this routine) that this Project either needs to read or to write.  

 

     So how do I find the location of this \<Project Name>\data folder?  There is a File Constant (File I/O Palette, File Constants) called Application Directory, that "Returns the path to the directory containing the application", which is just what you want -- in an .exe, it points to the folder containing the Executable, in a Project, it points to the Project folder.  Use this as the Directory to a Build Path function, write the string "Data" as the Name, wire it through (if you want) the OpenG function Build Path (which creates the folder if it is not there), and there you have it!  I wrap this in a VIG called "Data Folder" so it only does this when first called, then it "remembers" the Data Folder path from then on.

 

     Hope this straightens out your dilemma.

 

Bob Schor

0 Kudos
Message 12 of 16
(920 Views)

@Lchar wrote:

Your understanding and description is 100% correct. The customer still wants the Executable (as you mentioned a short-cut on the desktop) so that (I guess) the technician can easily start the SW even knowing nothing about LabVIEW and without the risk to make a mess (by mistake) in the code.

The Executable is placed in a created folder on the C drive, this is the same folder as the source code.

I can only debug my code with the bench PC, my development PC does not have everything installed to communicate with all devices (such as Twincat license for the Beckoff PLC).

When I run the source code on the bench PC, everything is working fine.

Only with the executable, one of the subVI ("Error Log.vi") is broken. Everything else is working fine as long as I don't press the button which start this "Error Log.vi". 

 

@BertMcMahan, yes the SW runs some VIs dynamically and also accesses (relative path) to few config / log files.

The VIs which are called dynamically are working fine with the executable, except for the one "Error Log.vi"  which includes some Unicode and OpenG VIs.

Inside "Error Log.vi", the Unicode and OpenG VIs are not run dynamically. 

Can it be the rootcause of the issue?

 

Lchar_0-1638866056099.png

 

I have taken over this project from a colleague who left and I am not very experienced with LabVIEW.

I am not 100% sure why the subVIs are run dynamically but my guess is: in order to have the "Wait Until Done" parameter to "False" so that it won't stop the background loop from the main VI.

Is it possible to have the same behavior without calling the VI dynamically?

 


That you are placing the exe in the same folder as the source code is an important hint, as is the fact that you are calling Error Log.vi dynamically.

 

The usual suspect when not find a dynamically called vi would be that Error Log.vi is not being included, however, if you are placing the exe in the same folder as the LVPROJ file then the relative path remains the same. Also the error you gave states the Error Log.vi cannot find a dependency, not that Error Log.vi itself cannot be found.

 

"Missing subVI Reverse 2D Array (String)__ogtk.vi in VI Error Log.vi.
Missing ..."

 

The problem is that the runtime engine and the development environment don't treat user.lib the same way, so Error Log.vi is not able to locate its dependencies.

 

See the attached example project in DynamicTestProject.zip. The error log button just opens a dialog that shows some text passed through an OpenG function. Very basic demo code.

 

If you run the "My Application" build spec, it should place DynamicTest.exe in the same folder as the project. If you run it, it should error out because it cannot find the OpenG dependency, just as you are describing. You can fix that by setting the viSearchPath token to the location where your dependencies are.

 

For my installation, that means adding viSearchPath="G:\Program Files (x86)\National Instruments\LabVIEW 2020\user.lib\*" to DynamicTest.ini. I'm sure your path will probably be different. You may also need to add other paths, depending on where other shared libraries might be installed.

 

Note that I have NOT set Error Log.vi to be always included. Normally, if I expected it at <application directory>\SubVIs\Error Log.vi, then I would set it to always include and create a "SubVIs" folder as its destination. As mentioned above, this only isn't necessary because, like you, I'm putting the exe in the source folder. This isn't how I would normally distribute to the end user. In fact...

 

Is that your only dynamic VI call? If so, then Error Log.vi is the only VI being utilized by the EXE, and I have to wonder: is there a reason why you want to call the source VI? See DynamicTestProject2.zip for another solution. If you just convert that call to a static VI reference, then both Error Log.vi and all it's dependencies should be automatically handled within the EXE.

Download All
0 Kudos
Message 13 of 16
(875 Views)

My original reply including zipped example projects was for some reason marked as spam. Not sure if it will be restored, but let's try the short and sweet version...

 

Fix 1:

 

When you build your exe, it should also create an INI file. Try setting the viSearchPath token to your user.lib folder.

 

Example: viSearchPath="G:\Program Files (x86)\National Instruments\LabVIEW 2020\user.lib\*"

 

I'm sure your path will probably be different, but I reproduced your issue as you are describing it and that worked for me. The problem is the the runtime engine and the development environment do not treat user.lib the same way, so Error Log.vi is not able to locate its dependencies that reside there.

 

Fix 2:

 

Convert that VI reference to a static reference. Then Error Log.vi and its dependencies should be properly handled within the exe. This is actually probably the better solution unless you actually have a reason you want to run the source VI itself. (If that's your only dynamic call, your other source VIs are not being used by the exe.)

0 Kudos
Message 14 of 16
(881 Views)

Thank you for your feedback JimB. I was quite busy this week so I didn't try much to debug the .exe.

I have tested your fix 1 but it didn't solve the issue with my program. However I can reproduce the same issue with your attached LabVIEW project and solve it with your fix 1... 

 

I am in Christmas vacation now, therefore I will investigate more your fix 1 and try your fix 2 after I am back.

You will hear from me again after CW02.

 

Have a nice Christmas break everyone!

0 Kudos
Message 15 of 16
(854 Views)

@Lchar wrote:

Thank you for your feedback JimB. I was quite busy this week so I didn't try much to debug the .exe.

I have tested your fix 1 but it didn't solve the issue with my program. However I can reproduce the same issue with your attached LabVIEW project and solve it with your fix 1... 

 

I am in Christmas vacation now, therefore I will investigate more your fix 1 and try your fix 2 after I am back.

You will hear from me again after CW02.

 

Have a nice Christmas break everyone!


Interesting... Honestly, I think that fix 2 is probably the better solution for you anyway, so please do try that one regardless of whether you get fix 1 to work.

 

However, in the interest of satisfying my curiosity 🤔... Did you include vi.lib in the viSearchPath token as well? I neglected to mention it in my answer, but I believe that you will need to add that as well since Unicode resides there.

 

If you did not, try using:

viSearchPath="C:\Program Files (x86)\National Instruments\LabVIEW 2020\user.lib\*;C:\Program Files (x86)\National Instruments\LabVIEW 2020\vi.lib\*"

 

0 Kudos
Message 16 of 16
(838 Views)