Using Labview VIs without runtime

[ABachmann]

Hi all,

here we have a quite heavy Labview 2012 application. It consists of several dozens of VIs. One of them is a firmware updater for devices we produce.

The task is to create a standalone firmware updater which shouldn't rely on an installed Labview runtime. So our idea was to create a DLL from this VI which provides the corresponding functions. Then these DLL functions may be called from another application.

The problem is that the produced DLLs rely on an installed Labview runtime. Is there any other way to access VIs (or Labview functions in general) without a dependency on the runtime? I mean besides using Cameyo.

[hicksc]

Hi ABackmann

Sorry but there's no way that I know of to access any LabVIEW functionality without the runtimes being present.

Kind Regards

[Norbert_B]

No, there is no other way. LV code always requires a LV RTE for execution as long as the executable code is generated with LV itself.

You have to see the LV RTE like the .NET Framework. Having .NET assemblies (EXE/DLL) will always require the correct .NET Framework to be installed on the machine. I don't know if Cameyo helps here, but if it does, it should also work out with LV applications.

There is a "workaround" though, which could not work correctly with your code, but you can give it a try:

There is a "C-Code Generation Module" available for LV, which converts LV uncompiled source code in uncompiled C-Code. The main application area for this is programming microcontrollers. You can compile this code with a C-Compiler in a second build step. Please note that the C-Code is designated for up to 32-bit systems, not 64-bit. So manual adoption of the C-Code might be necessary there....

The application build with that uses a RTE which is already part of any Windows-based computer.

Norbert

Edit: Note also, that the mentioned "workaround" is not supported from the point you get the C-Code. So NI does not support a correct compilation of the code into a C-based application using "any" C-compiler. As seen in the link, the module is targeted for non-Windows systems like 8-, 16- or 32-bit microprocessors.

[ABachmann]

We don't have the C-Code Generation Module yet, but this may be a possible solution in the future (we plan to upgrade to Labview Professional).

It would really come in handy in the future if the application builder would be able to build such self-contained packages, with just the essential runtime features. For now, we seem to have only Cameyo as a solution for our needs. We tested it and it works fine, but we would prefer an officially supported solution from NI...

[Yamaeda]

What's the problem with installing a runtime?

/Y

[Mark_Yedinak]

---

@ABachmann wrote:

We don't have the C-Code Generation Module yet, but this may be a possible solution in the future (we plan to upgrade to Labview Professional).

It would really come in handy in the future if the application builder would be able to build such self-contained packages, with just the essential runtime features. For now, we seem to have only Cameyo as a solution for our needs. We tested it and it works fine, but we would prefer an officially supported solution from NI...

---

In any evironment executables will always rely on certain libraries to be installed on a machine in order to run. In many Windows applications they are relying on the libraries that get installed by the OS itself. That is one of the reasons a Windows OS install is so large. It is not reasonable to suggest that applications should be entirely self contained. Maintenance and bug fixes on the "shared" components would be a nightmare under this scenario.

[ABachmann]

The problem is that it isn't possible to download a 200+ MB runtime everywhere around the world. If a farmer in the Australian bush only has a 19k modem connection, it is hardly a solution to have him download the hundreds of MB for the runtime for a small updater which is only some hundred KB of size. This is a real world scenario, we had this.

So we had the idea to create a DLL of some VIs and put around some glue code. This would be the fastest solution. But without a way to do this, we have to reimplement these VIs in another language. It is like reinventing the wheel.

[Yamaeda]

You create 2 installers, one which contains the RTE and send it on a cd. Further patcher can be the .exe only of a few megs. The RTE is a one time install.

[Mark_Yedinak]

---

@ABachmann wrote:

The problem is that it isn't possible to download a 200+ MB runtime everywhere around the world. If a farmer in the Australian bush only has a 19k modem connection, it is hardly a solution to have him download the hundreds of MB for the runtime for a small updater which is only some hundred KB of size. This is a real world scenario, we had this.

So we had the idea to create a DLL of some VIs and put around some glue code. This would be the fastest solution. But without a way to do this, we have to reimplement these VIs in another language. It is like reinventing the wheel.

---

I understand your problems but other languages will require specific libraries to exist on the system in order to run. They will be no different in that regard. They may benefit from using the libraries that are included with the OS installation but they are still using those items and if not there, such as the DotNET example listed above they will need to be downloaded as well. NI has made some improvements in LV 2011 that can trim back some of the RTE elements that get installed. As suggested though you can always create two installers. The RTE does not need to be included once they are already on the system.