Calling Code from Other Languages

What happens if you have to use some code written in another language (such as C, C11, or Visual Basic)? Or if, for some reason, you just miss typing in all those semicolons in your familiar text-based code? LabVIEW does give you some options for interfacing with code from other languages. If you are thinking about writing all your code in C or C11, you should check out LabWindows/CVI (available from National Instruments), a programming environment very similar to LabVIEW; the main difference is that C code replaces the graphical block diagram. But if you'd like to (dare we say it?) actually have fun programming, then stick to LabVIEW and use conventional code only when you have to.

You may want to skip this section if you aren't familiar with writing code in other programming languages such as C, or if you don't expect to need to interface LabVIEW and external code.

LabVIEW gives you three options to call external, compiled code:

• Using the command line with System Exec.vi.

• Calling dynamic linked libraries, or DLLs (DLLs apply only to Windows; for Mac OS X and Linux, you can call Frameworks and Shared Libraries, respectively) with the Call Library Function Node.

• Interfacing to compiled code using a Code Interface Node.

Sysetm Exec.vi is the simplest option to launch a separate executable or program that does what you need. On Windows, Linux, and Mac OS X systems, you do this with the System Exec function (Connectivity>>Libraries & Executables palette), shown in Figure 14.37.

Figure 14.37. System Exec.vi

If you have dynamically linked libraries: Dynamic Link Libraries (.dll) on Windows, Shared Libraries or Shared Objects (.so) on Linux, and Frameworks (.framework) on Mac OS X, you can use the Call Library Function Node in LabVIEW (Connectivity>>Libraries & Executables palette), shown in Figure 14.38.

Figure 14.38. Call Library Function Node

Finally, if you want to write your own C code and embed it into LabVIEW, you should use the Code Interface Node (CIN) (Connectivity>>Libraries & Executables palette), shown in Figure 14.39.

Figure 14.39. Code Interface Node

This section talks about interfacing with lower-level compiled code in other languages, but you can also use LabVIEW to communicate with inter-application frameworks like ActiveX and .NET. You'll learn about these in Chapter 16, "Connectivity in LabVIEW."

LabVIEW can also go the other direction. If you need your external code to call a LabVIEW program, LabVIEW can export a VI into an executable (.exe), dynamic link library (DLL) on Windows, shared library (.so) on Linux, and framework (.framework) on Mac OS X. We discussed this capability briefly in Chapter 3, "The LabVIEW Environment."

Using the Call Library Function Node to Call DLLs

We'll look into a little more detail at one of the more common ways you might need to call external code: when it is provided in the form of a DLL.

DLLs are small, compiled libraries in a .dll file that encapsulate some functionality and export a set of functions that other applications (like LabVIEW) can call. Usually, you need good documentation to be provided with a DLL for you to be able to use it, because you need to know what the functions are and how the data should be passed to and from them.

Although we will refer to the external libraries here as DLLs, which are for the Windows platform, the exact same steps would apply to calling Frameworks under Mac OS X or Shared Libraries under Linux.

Watch Out! Calling DLLs incorrectly or calling DLLs that are buggy can make your system become unresponsive, crash LabVIEW, or even crash your entire computer. Be sure you've saved your work and test carefully when using DLLs. And in some cases, keep the fire extinguisher nearby!

Activity 14-4: Calling a DLL in LabVIEW

In this activity, you'll see how to call a DLL. To use a simple DLL that you already have on your system to compute the mean value of an array, we'll call a math-analysis DLL that already ships with LabVIEW, the lvanlys.dll. This DLL is actually used by many of LabVIEW's math functions.

1.	Create a VI like the one shown in Figure 14.40, with an input array of numerics and an output called "mean." Save your VI as Calling a DLL.vi. Figure 14.40. Calling a DLL.vi front panel
2.	Now, locate the DLL lvanlys.dll located at resource\lvanlys.dll beneath your LabVIEW installation.
3.	Open a new VI and put a Call Library Function Node on the block diagram (from the Connectivity>>Libraries & Executables palette). Figure 14.41. The Call Library Function Node on the palette Right-click on the Call Library Function Node and select Configure . . . from the pop-up menu. You'll get a window like the one shown in Figure 14.42. Figure 14.42. Call Library Function configuration window
4.	This is where you define what function you wish to call from the DLL, and what your input and output parameters are. Follow these steps to configure the DLL: a. First, tell it which DLL we are using. Click on the "Browse . . ." button and navigate to resource\lvanlys.dll, which you located earlier. Note how the path to the DLL shows up in the "Library or Path Name" field. b. Now click on the "Function Name" field. You'll see this DLL has LOTS of functions. We're going to use a function called Mean_head. Scroll down the list and select "Mean_head" as your function name (see Figure 14.43). Figure 14.43. Selecting the function name in the DLL c. Now that you've selected your function, you'll need to know what kind of inputs and outputs it expects. This is why it is essential for you to have proper documentation on your DLLs, because unlike functions in LabVIEW, the DLL functions here don't automatically show you what inputs and outputs are expected. You need to at least know what the function prototype looks like. So, here is your documentation for the function Mean_head: The function Mean_head has the following function prototype in C: long Mean_head(void *xH, void *mean, void *dsperr);

If you aren't familiar with C language, this means that the function Mean_head returns a long (32-bit) numeric, and takes in as arguments a pointer called xH, a pointer called mean, and a pointer called dsperr.

This function takes an array of numerics referenced by the pointer xH and calculates the mean, placing its value in the memory location referenced by the pointer mean. If there is an error, its numeric code is referenced by the pointer dsperr.

d.	So your first step is to define the Return Type parameter. Looking at the previous documentation, you can see that this function returns a long numeric. Click on the Parameter box and choose "return type." From the "Type" box below, choose "Numeric." When you do so, a new option appears, called "Data Type." Make sure it is set to "Signed 32-bit Integer." It should look like Figure 14.44. Figure 14.44. Setting the "return type" parameter (return value) on the DLL function
e.	Now that you've set the return type, it's time to define the arguments, or input parameters to the DLL function "Mean_head." Looking at the documentation, we see that there are three arguments: *xH, *mean, and *dsperr. These need to be entered in the correct order. Click on the "Add a Parameter After" button on the dialog. The Parameter field will say "arg1." Change this to say "xH." The type should be "Adapt to Type," and the data format should be "Handles by Value." Notice how the Function prototype at the bottom of the dialog is reflecting what you have entered, as seen in Figure 14.45. Figure 14.45. Setting the "xH" input parameter (argument) for the DLL function
f.	Repeat the previous step for the next two parameters: *mean and *dsperr. The "mean" and "dsperr" parameters should also be set to "Adapt to Type" and "Handles by Value." Your function prototype should look like the one in Figure 14.46. Figure 14.46. The final function prototype Make sure your function prototype matches EXACTLY the one in Figure 14.45 and, in particular, that your parameters are in the right order.
g.	Hit OK. You've configured your DLL! Your Call Library Function Node function will now look like Figure 14.47. Figure 14.47. Your Call Library Function Node after you have configured it
h.	Notice you have three input terminals and four output terminals. The three input terminals are your arguments, and the four output terminals are the return type plus the pointer data from each of the three inputs.
i.	Now wire the VI's block diagram as shown in Figure 14.48. You have to provide "dummy" inputs to the arguments, even if they represent outputs, so that LabVIEW knows what kind of data type you are using (due to the fact that these parameter types were configured as "Adapt to Type"). To do this, wire numeric constants into the input, as shown in Figure 14.48. Make sure to set the second input parameter's numeric constant to a DBL type by popping up on the numeric constant and choosing Representation>>DBL. Figure 14.48. Calling a DLL.vi block diagram And, make sure the last input parameter is an I32 numeric by selecting Representation>>I32 from its pop-up menu.

Error Cluster From Error Code.vi

Use Error Cluster From Error Code.vi (Programming>>Dialog & User Interface palette) to convert the error or warning code to an error cluster. This VI is useful when you receive a return value from a DLL call or when you return user-defined error codes.

If error in contains an error when the VI is run, then the "Error" case of the Case Structure will execute. Note that we pass out Not a Number (NaN) in this case. It is a common convention to output Not a Number out of a mathematical function when an error occurs.

j.

Now type a few values on the front panel's Input Data array, and run the VI to see it compute the mean.

If all of this seems complicated for such a simple function, it is! Using pure LabVIEW is easier and much more fun. That's why you should try to avoid DLLs unless you have a good reason to use them, such as needing a routine only available as a DLL or in some speed-critical application.

There are many other complex issues involved in LabVIEW's communicating with external code. Because many of these are highly dependent on the processor, operating system, and compiler you're using, we won't attempt to go any further into discussing DLLs or CIN functions. If you'd like more details, consult the LabVIEW help documentation and the application notes at http://zone.ni.com.