LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

How to include properly OpenG and Unicode into the executable.

Hello all,

 

This is the first time for me to create an executable so I am maybe doing a very beginner mistake. I am using Labview 2020.

 

I have my development PC where I build the executable.

 

And then I copy everything (source code + executable) on the bench PC.

When I run the source code from the bench PC, everything is ok.

When I run the executable from the bench PC, one VI which is using OpenG and Unicode subVIs, is not working. It appears with a broken arrow and this message when pressing the arrow:

 

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

 

However, both library (OpenG and Unicode) are installed on both PC at the same location:

C:\Program Files (x86)\National Instruments\LabVIEW 2020\user.lib\_OpenG.lib

C:\Program Files (x86)\National Instruments\LabVIEW 2020\vi.lib\addons\Tools\Unicode

 

I don't know what is the proper way to include both library in my executable build?

I have tried some ugly things, such as deleting the library folder and copying every VIs in my project folder, but nothing worked.

 

I would really appreciate a hint here.

 

Thanks!

 

 

0 Kudos
Message 1 of 16
(2,300 Views)

It has been a while since I deployed an Executable on a PC that didn't have LabVIEW itself installed (recently I've been developing-like-crazy, but testing on my Development PC).  I use OpenG all the time, but have no experience with Unicode routines (which I didn't think was all that standard in LabVIEW -- you aren't using NXG, are you?).

 

My code tends to use "standard LabVIEW", with few external Libraries.  I do use OpenG, and in some cases, a modified (by me) version of GXML (both found on the LabVIEW Tools Network).  When I create the Build Spec for my routine, I only need to specify the Top Level VI, and everything else gets included in the Build (I don't load different routines at Run Time, though I'm currently experimenting with doing something like this ...).  I did try (once) to build an Installer (I recall I had a Tech Support Engineer on the phone with me), and was not too pleased with the complexity of it all, so stuck with the following, "manual", method of deployment:

  1. Build the Executable in (say) LabVIEW 20XX (32-bit).
  2. Place the Executable (and its accompanying Folder structure) in some place like \Users\Public\Public Documents.
  3. Download from NI the Run-Time Engine appropriate for LabVIEW 20XX (32-bit) and install it on the Remote machine (where you placed the Executable).
  4. I recommend putting a Shortcut to the Top Level VI (step 2) on \Users\Public\Public Desktop, particularly if you want all users to have access to this program.

I noticed when I did a Web search for "LabVIEW Runtime Engine" I found this Knowledge Base Article that definitely appears to have more and (probably better!) information on this process than what I have just described!  Learn from the Experts ...

 

Bob Schor

0 Kudos
Message 2 of 16
(2,241 Views)

When you create an executable it does not matter what VIs are installed on the target computer since the executable does not reference any VIs outside of itself (if you don't build complicated plugin architectures at least).

 

The conclusion that this has to do with using the Unicode and OpenG libraries together also sounds far fetched. They do not have and dependencies on each other, and are also name spaced, so it's hard to imagine that one will cause the other to have problems.

 

It more likely has something to do with the settings in your Build Specification for your executable. What did you select in Advanced Exclusions in the Build Specification?

Rolf Kalbermatter
My Blog
0 Kudos
Message 3 of 16
(2,230 Views)

I don't know about the other guys but I build installers and executables for non-LV PC's constantly. It's a breeze.

 

It sounds like your build spec is messed up. I'd create a new one (in your main VI, click Tools then Build Application (EXE) from VI). Fill out the name and such in the build spec but leave it alone other than that.

 

Build it, then in the Project, right click Build Specifications and select New- Installer. Again, fill out Product Information as you normally would, then go to Source Files and select the build spec you just made, then click the "Right" arrow to move it to the list on the right.

 

Next go to Additional Installers and make sure it's set to Automatically Select.

 

Build that and it'll create a new directory with your installer stuff. Copy that entire directory to your bench PC and run the installer and see if that works.

 

You don't want to move your source code to the non-LV computer, and moving the exe by itself is usually more trouble than its worth. I only do that if the automatic method fails somehow which hasn't been a problem for several years.

 

 

0 Kudos
Message 4 of 16
(2,210 Views)

On your existing build spec, go to the "Additional Exclusions" tab and uncheck everything there.  

 

These ones are checked by default:

Kyle97330_0-1638472677378.png

Normally the EXE builder is pretty good about determining which polymorphics, inlines, and library members it can remove with no problems, but if it made a mistake then unchecking these checkboxes can fix that.  It will add a bit of bloat to your built EXE though.

0 Kudos
Message 5 of 16
(2,175 Views)

Hello everyone,

 

Thank you for your feedback!

 

I don't know if I was clear but I have LabVIEW installed on both PC (my development PC and the bench PC).

But on the bench PC i don't have the license to build an .exe for example.

 

On both PCs I have installed labview 2020 the same way (the standard SP1 installer), and the external libraries with VIPM. 

I usually develop on my PC at my desk with the big screen and then I copy the source code to the bench PC and debug on the bench PC.

Only now that we want to deliver the bench, I am trying to create a .exe so that the technician can easily use the SW.

The customer has access to the source code on the bench PC if they want to make any changes.

 

For now I have tried to recreate the build spec and to uncheck everything from "Additional Exclusions" but it didn't work...

I also tried to create a virtual folder "OpenG functions" and to add the needed OpenG VI to that folder. Then in the "Source Files" to add those VIs in the "Always included" section but it also didn't work...

 

For now as a very dirty solution, I have just created my own VIs with the OpenG and Unicode code directly (so I am not using the libraries anymore). This is working fine but I am clearly not satisfy with this solution.

 

Attached are some screenshots from my build properties, maybe you can see something wrong.

 

The bench is not available until end of next week, so I will have to wait before testing again.

My next potential ideas would be to reinstall LabVIEW on my development PC, and/or to create an installer (and not an execute) as suggested by BertMcMahan.

0 Kudos
Message 6 of 16
(2,093 Views)

Just to clarify, you have to make an exe AND an installer. The installer, well, installs the exe along with all necessary support components.

 

Are you launching anything dynamically? You may need additional "Always includes".

 

Are any of the OpenG VI's modified? If so, see this thread: https://forums.ni.com/t5/LabVIEW/Missing-SubVIs-when-generating-exe/td-p/1016669/page/2?profile.lang...

0 Kudos
Message 7 of 16
(1,946 Views)

@Lchar wrote:

Hello everyone,

 

Thank you for your feedback!

 

I don't know if I was clear but I have LabVIEW installed on both PC (my development PC and the bench PC).

But on the bench PC i don't have the license to build an .exe for example.

 

On both PCs I have installed labview 2020 the same way (the standard SP1 installer), and the external libraries with VIPM. 

I usually develop on my PC at my desk with the big screen and then I copy the source code to the bench PC and debug on the bench PC.

Only now that we want to deliver the bench, I am trying to create a .exe so that the technician can easily use the SW.

The customer has access to the source code on the bench PC if they want to make any changes.

Wait a minute.  Let me see if I have this correct:

  • You have a Developer PC with LabVIEW + a license that lets you build Executables.
  • You have a Bench PC that has LabVIEW, but no license to build Executables.
  • You have the Source for your Project, and external Libraries from VIPM on both machines.

Let's forget, for the time being, Executables.  Let's call the owner of the Bench machine the "User".  As long as the User has the latest (or "most correct") version of your source (LabVIEW) code, they should simply be able to open LabVIEW and run the Top Level VI (which, I suppose, is what you do on your Developer PC).  If they make changes to the Program, it becomes their responsibility to "not mess up the code too badly" -- they also run the risk that when you come out with Version 1.1, it won't be so easy to migrate their "User-mangled Version 1.0", but that's on them.

 

Now let's talk Executable.  Since they already have LabVIEW installed on their PC, they already have the LabVIEW Run Time Engine.  If you build an Executable, copy it to a convenient location on the Bench PC (again, I recommend \Public Documents) and put a Short-Cut to the Executable on the Public Desktop (so everyone can "see" it, but not "mess with it" easily), then they can run, regardless of who logs on, just by clicking the Desktop Icon for your program.  When you update the code, you either replace the old Executable or create a Version 1.2 which you save in a different Build folder.

 

Or am I missing something?

 

Bob Schor

0 Kudos
Message 8 of 16
(1,918 Views)

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?

 

0 Kudos
Message 9 of 16
(1,898 Views)

Try adding "Error log.vi" to Always Included.

0 Kudos
Message 10 of 16
(1,872 Views)