LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Can a LabVIEW dll be run by other SW tools?

Solved!
Go to solution

I wonder what the purpose is of to create a LabVIEW dll? I have tried this feature and it works fine as long as you call the dll in LabVIEW. However, when the dll is called by for example MATLAB I get several issues. Should I expect a LabVIEW dll to work with other SW tools or not? 

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

It should work with other software packages.  You will need at least the LabVIEW Runtime Engine installed to use the DLL.


GCentral
There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines
"Not that we are sufficient in ourselves to claim anything as coming from us, but our sufficiency is from God" - 2 Corinthians 3:5
0 Kudos
Message 2 of 7
(3,689 Views)

Use of a LabVIEW DLL from within LabVIEW is a pretty roundabout way to go about it. Better is to directly use the according VI libraries as it strips out several potential performance bottlenecks.

 

What you have to watch out when creating a DLL from LabVIEW code for use in other environments is that you do not use LabVIEW native datatypes such as String and Array handles, and preferably also no clusters in the API interface. String and Array handles are LabVIEW specific datatypes that not only are difficult to interpret and use correctly by other environments but also only can be managed by the correct LabVIEW memory manager functions which are not really possible to teach Matlab and other environments to use, and even pretty hard to get right in C, since the calling application needs to locate the correct LabVIEW runtime the DLL is loaded into and running it.

Clusters are usually problematic since different environments have different constraints in how they like to align elements in their equivalent collection datatype (and their is no way to configure a cluster in LabVIEW to use anything but LabVIEW handles for strings and arrays inside the cluster.

 

So avoid clusters and configure the DLL interface to use C pointers for arrays and strings!!

 

If you watch out about these it is definitely possible, although interfacing DLLs is serious low level C programming no matter how you go about it and accordingly requires some good understanding of how DLL functions are called by a C compiler in order to really make that work reliable. In addition to that you also need to understand the specific intricacies of the environment you are using about calling DLL functions, be it Matlab, Visual Basic or Python, etc. Each of them has its very own specific methods to create an import definition for a DLL function, which is both very specific to that environment as well as very much low level defined by the nature of a DLL function interface. It's all located very close to the bare metal assembly code level of what executes directly on the CPU without any Active X type libraries or .Net managed code environment. One single wrong definition usually means directly some access violation with protection fault error if you are lucky, or obscure memory corruptions if you happen to be unlucky.

Rolf Kalbermatter  My Blog
DEMO, Electronic and Mechanical Support department, room 36.LB00.390
Message 3 of 7
(3,682 Views)

Rolf, Thanks for your reply.

Well, I have tried to create a simple dll in LabVIEW (two numerical inputs, adding the numbers, and output the sum).

That dll works fine when I use it in LabVIEW but it create issues when I try to load it in MATLAB, even if use the same machine where both LabVIEW and MATLAB are installed (missing dlls ). I have been in contact with Mathworks and they cannot help me.

 

MATLAB asks for additional dlls:  (extcode.h, fundtypes.h, lv_epilog.h, lv_prolog.h, and platdefines.h).

Even if I add those I still get errors; See below.

My questions is: Should it be so difficult to use a LabVIEW dll in MATLAB? What is the problem, MATLAB or LabVIEW?

I do not find examples that show how to use a LabVIEW dll in MATLAB but several of how to run MATLAB scripts in LabVIEW!!!

 

BR/Mats

 

 

Warning: Message from C preprocessor:

lcc preprocessor error: C:\MATLAB\LabVIEW_DLL\My_DLL\platdefines.h:118

C:\MATLAB\LabVIEW_DLL\My_DLL\extcode.h:14 C:\MATLAB\LabVIEW_DLL\My_DLL\SharedLib.h:1 #error directive:

"We don't know the Compiler"

lcc preprocessor error: C:\MATLAB\LabVIEW_DLL\My_DLL\platdefines.h:352

C:\MATLAB\LabVIEW_DLL\My_DLL\extcode.h:14 C:\MATLAB\LabVIEW_DLL\My_DLL\SharedLib.h:1 #error directive:

 

> In loadlibrary at 317

  In data_logging_32bit at 15

Warning: Warnings messages were produced while parsing.  Check the functions you intend to use for

correctness.  Warning text can be viewed using:

[notfound,warnings]=loadlibrary(...)

> In loadlibrary at 343

  In data_logging_32bit at 15

 

 

0 Kudos
Message 4 of 7
(3,660 Views)

Well the DLL interface was developed about 30 years ago, not with ease of use for non programmers in mind, but with what the CPUs at that time could reasonably handle. That did not include complicated type library descriptions of the interface, nor any managed code interface like in .Net. With such technologies involved Windows 3.0 would have been unable to load on a 33MHz 80386 CPU in any reasonable time.

If you wanted to do any advanced things you had more often than not anyhow to get down to assembly programming, so the difficulties of calling a C interface was not even considered a disadvantage in comparison to the rest but in fact a steep improvement to doing your own assembly programming.

Backwards compatibility concerns has prevented anyone from significantly enhancing the interface specification in any way and new technologies like ActiveX and .Net on Windows or Objectve C on Mac have further marginalized the need for such improvements. But any of these techniques is platform specific and with its own complications so the traditional C based DLL interface is still the "least common denominator" for all programming environments. But it comes with its trouble.

Add to that that Mathworks Inc and NI are in many ways competitors. NI choose from early on to show how to use Matlab from within LabVIEW as they recognized that there are certain things that Matlab simply does better but Mathworks always showed a pretty hesitant way to support the other side around, maybe because they felt their Matlab environment could do everything that LabVIEW can do at least as good, or maybe they felt to threatened by LabVIEW. You may have to decide about that.

 

As to integrating a simple DLL which only uses standard numeric types you could probably circumvent the issues about the various missing header files by completely eliminating the #include "extcode.h" line from the generated LabVIEW header file for your DLL. If you use a current LabVIEW version the resulting datatypes used in the header file should be all C99 compatible inttypes.h types and provided the Matlab importer understands C99 you should be pretty much fine without any LabVIEW specific imports and could probably get away with removing extcode.h completely and inserting an include for inttypes.h instead. If you start to use clusters (C structs) in the interface things get a lot more complicated (the lv_prolog.h and lv_epilog.h get quite important on Windows to get the struct definitions properly aligned).

 

All in all calling DLLs through exported functions is a C programming problem on several levels. It requires some understanding about what a C compiler does when calling functions. But it also requires knowledge about how to provide proper memory buffers for parameters to those functions, and specific knowledge about each function how it exactly expects these buffers to be prepared. There is simply no point and click only wizard like solution that can work reliably for this interface!

Rolf Kalbermatter  My Blog
DEMO, Electronic and Mechanical Support department, room 36.LB00.390
0 Kudos
Message 5 of 7
(3,644 Views)
Solution
Accepted by topic author Bjärred

Hi Rolf, I agree to what you write. I worked successfully with ActiveX applications long time ago (2000 - 2002) and that worked fine.

Anyway, the dll quick fix solution seems to be a dead end and that explains why no examples are found. Are LabVIEW dlls mostly used to hide how the implementation looks like?

Thus, I stay with a LabVIEW executable to work as an image data collector. I use Matlab to carry out the analysis of image files later on.

The return of investment to create one application (based on Matlab and LabVIEW dlls) that do it all are too poor in my case.

BR/Mats

 

 

Message 6 of 7
(3,632 Views)

It should be easy enough to make a LV executable that takes the image and analyse it through Matlab.

G# - Award winning reference based OOP for LV, for free! - Qestit VIPM GitHub

Qestit Systems
Certified-LabVIEW-Developer
0 Kudos
Message 7 of 7
(3,586 Views)