Solutions  Products  Perspectives Support  Community About Contact Us

Home > Tutorials > An Overview of Accessing DLLs or Shared Libraries from LabVIEW

An Overview of Accessing DLLs or Shared Libraries from LabVIEW Bookmark & Share
Publish Date: May 01, 2009 | 93 Ratings | 4.02 out of 5 | Print | 7 Customer Reviews | Submit your review
Share

Overview
Ratings
Dynamic Link Libraries (DLLs) provide a way for programs to access external code. The Windows concept of a DLL is also found on
Rate this document
Macintosh and UNIX systems, but is usually called a shared library or shared object file.
Select a Rating

DLLs are sections of code that are linked to the main program at run time (dynamically linked). This has several advantages. The first is Answered Your Question?
space. If many applications share a certain algorithm, you can compile it once as a DLL, and then use the same code in all the Yes No
applications. DLLs also provide a way for code to be distributed in a fashion that easily allows higher level programs to access the code. A
good example of this are hardware drivers, in which the interface between the application software and the hardware is often through a Submit
DLL.

LabVIEW can access functions contained in DLLs via the Call Library Function Node.

Table of Contents
1. Gathering the necessary information
2. Configuring the Call Library Function Node
3. Declaring a function call to a library function threadsafe (reentrant)

1. Gathering the necessary information

In order to call a function from a DLL, you need to know four pieces of information:
1. The library file in which the code for the function resides
2. The name of the function as it appears in the library
3. The number and type of arguments the function requires, including the return type
4. The calling convention
Items two and three together make the function prototype.

If you are the author of the library, you should already have this information. If the library is from a third party, you should consult the
documentation that came with the library to gather this information. (If you are trying to access a function that is part of the Win32 SDK,
see the link below.) You may find that you need to look in the header (.h) file included with the DLL in order to find the function prototype.
LabVIEW is able to call functions with either C or standard (PASCAL, WINAPI) conventions. Most DLLs use standard calling conventions,
and this can usually be assumed, if it is not explicitly stated. If the calling conventions are wrong, LabVIEW will crash when your VI tries to
call the function.

When you have the information, it should look something like this:

Library: mydll.dll
Function Prototype: void MyFunction(int a, double* b, char* string, unsigned long arraysize, short* dataarray);
standard
Calling Conventions:

Unfortunately, in order to successfully call this function, you need to understand what the function expects. The first problem is that integer
data types are not necessarily consistent in size from one platform to another. LabVIEW alleviates this problem by refering to all integers
in a consistent manner. To convert from LabVIEW's notation, to the notation of your particular platform, use the following table:

LabVIEW Win32 Win16 Macintosh (PowerPC) Most UNIX Systems

int8 signed char signed char signed char signed char

int16 short int, short short short

int32 int, long long int, long int, long

uInt8 char char char char

uInt16 unsigned short unsigned int, unsigned unsigned short unsigned short
short

uInt32 unsigned int, unsigned unsigned long unsigned int, unsigned unsigned int, unsigned
long long long

Furthermore, you also need to know what the function expects in terms of pointers. Some parameters are passed by value, and some are
passed by pointer. For those passed as pointers, the function may expect a single value, or it may expect the starting location of an array
of values. Knowing which one is critical if you are to successfully call the library function. In the example above, you can guess from the
parameter names, and read in the (hypothetical) manual that dataarray should be a pointer to an array of shorts, while b is a pointer to
one double value.

The final piece of information is that strings are generally passed to DLLs as C strings. A C string is an array of chars, and as such, is
normally seen in function prototypes as "char*", a pointer to a character array. Incidentally, C functions know when they've reached the
end of a string because they are always terminated with a null character (ASCII value 0x00).

With all of this information, you can write a slightly revised function prototype (assuming a Win32 OS):

void MyFunction(int32 a, double* b, char* string, uInt32 arraysize, int16* dataarray);

where:
b is a pointer to one double value,
string is a C String pointer, and
dataarray is a pointer to an array of int16s
2. Configuring the Call Library Function Node Back to Top
Once you've gathered all of the necessary information, you are ready to set up the Call Library Function Node. The first thing to do, of
course, is to place a node on the block diagram. The Call Library Function Node is found on the Functions Palette >> Advanced >> Call
Library Function. After placing the node on the diagram, you must configure it. Popup on the node and select "Configure..."

This will bring up a dialog that allows you to configure the function call.

On this dialog, enter the path to the desired library, the name of the function, and the calling conventions. Finally, set up the function
prototype by using the Parameter of the dialog. Specify the return type, and then add parameters to the prototype using the "Add a
Parameter Before" or "Add a Parameter After" buttons. Use the dropdown boxes "Type," "Data Type," and "Pass" to specify the proper
data type and how the parameter is passed.

Once finished, the node will display the appropriate terminal data type on the block diagram:

If the library file cannot be found, or the function cannot be found within the library, you will get a broken run arrow. Click the broken run
arrow to display the error list and find the offending node.
3. Declaring a function call to a library function threadsafe (reentrant) Back to Top
If you know that the function you are calling in the library is threadsafe, you may inform LabVIEW by appropriately configuring the node. If
the node is not configured as a threadsafe call, the call is assumed to be non-threadsafe, and is run in the User Interface thread. This
ensures that two calls are not made simultaneously to a non-threadsafe function. If the function is threadsafe, however, it should be
configured as such, as this leads to performance improvements.

To configure a call library function as threadsafe, change the dropdown box that says "Run in UI Thread," to "Reentrant."

Having done this, the top of the node changes from orange to yellow, indicating that the call is reentrant.

---->

See Also:
MSDN Library
Back to Top

Customer Reviews

7 Reviews | Submit your review

DLL Hangs in LabVIEW - Feb 16, 2012

By Richard Vasquez, HydraElectric.
Depending on who writes the dll file, LabVIEW has a problem releasing the dll back to the system. To cause the problem: 1) Call the vi with the dll
and run it. 2) Close that vi. 3) Repeat Step #1, and the dll will FAIL. 4) The only way to clear this error is to shut down LabVIEW and reopen it. The
dll will work again. Why does LabVIEW not release the dll back to the system?

remarks to comments - Mar 15, 2010

By Rolf Kalbermatter, CIT Engineering Nederland BV.
@Roy: While the types mentioned are WinAPI types and could be argued to be common, they are not really in terms of any C standard. So has
every other platform it's own specific types and even every major multiplatform project has its own "basic" types for many years. @Peter: As Joel
points out the Call Library Node supports structures. They just should not contain pointers to make it not to difficult. @Spike: There is the import
library wizard who does exactly what you ask for, using the C header and it is in LabVIEW since at least version 8.2 which came out long before
you made that comment.

oddly labor-intensive - Apr 22, 2008

By Spike McLarty, Dosadi.
This seems like a strangely awkward and labor-intensive way to support external libraries. Why not define a file format for declaring *all* the
functions in an external DLL, and then just import that file and be able to use all the functions more or less as built-in functions? Then developers
could *share* those files, instead of making each developer figure out and enter the prototype for each external function, each time! My company
markets one of these 3rd party DLLs, and we'd provide the declaration file, if NI would just support it! (Hint: Every other language we support, 16 at
last count, lets us give our customers a declaration file.)

About structures - Mar 6, 2008

By Joel Castillo, .
In this article: Passing a Variety of Data Types from DLL to LabVIEW http://zone.ni.com/devzone/cda/epd/p/id/1288 It is shown how to handle
Clusters as structures in the DLL. Very usefull.

Forgets one key lack: - Jul 3, 2007

By Peter Kucera, Gebr. Swoboda GmbH.
The function is not capable of handling C Structs. Those are heavily used at third party driver DLLs.

Good, but lacks - Apr 9, 2007

By Roy A. Kesmodel, Morgan, a Stanley Company.
Good start, but should provide more. For instance, what if your function is type BOOL? I found out that it is equivalent to INT32 and am assuming
that a return of 0 is FALSE and 1 is TRUE, but had to call NI to find out. What else is left out?

Very good article, however: - Mar 9, 2004

By Brian Brooks, UCLAN.
Did not make clear whether function parameters 'names' should be typed into the Labveiw prototype. Also a simple example of the syntax of the
calling conventions would help this decision

View more reviews

Solutions Orders Company Support

Engineer
Ambitiously.™ Semiconductor

Automotive
Order Status and History

Order by part number

Leadership

Careers
Downloads

Product Documentation

Aerospace, Defense, & Activate a Product Investor Relations Discussion Forums

Government
Retrieve a Quote Newsroom Submit a Service Request
Academic & Research
Terms of Service Corporate Responsibility Site Feedback
Wireless
Supply Chain & Quality
Electronics
Events    
Energy

Industrial Machinery

Heavy Equipment

Partners

United States LEGAL |  PRIVACY © 2020 NI. ALL RIGHTS RESERVED.