Connecting LabVIEW to 3rd Party Software Packages

Updated Jul 15, 2024

Environment

Software

  • LabVIEW

Engineers and scientists often use two or more software tools as part of their work process, many times requiring some type of connectivity between the tools. This document is intended to describe the most common methods that can be used to extend LabVIEW, in order to connect to another software tool.

Use-cases of connecting LabVIEW to other software packages include the following: 

  1. Design teams can interact more seamlessly by using LabVIEW for certain parts of projects or workflows, and the other software for separate parts
  2. LabVIEW users can have access to specialized or vertical technologies and IP (intellectual property) that aren't included in the LabVIEW software. an example of this would be adding custom signal processing routines from a biomedical application to LabVIEW.
 

Example Software Packages

Consider a few example software packages that may be used in conjunction with LabVIEW. In some cases, 3rd party toolkits for LabVIEW exist for connectivity.


Functions Available in LabVIEW for Connectivity

This document will describe multiple methods available in LabVIEW to connect to other applications. These methods are available in LabVIEW in the functions palette Programming>>Data Communication >> Protocols

datacom.png

File I/O

Description

LabVIEW can communicate with 3rd Party tools using the File I/O features included with LabVIEW.

Communication using File I/O involves one program creating and saving the file, and the other program opening and accessing the file. Thus, there is a type of handshaking required, where the file must be saved before it can be opened and accessed.


 

File I/O is an easy way of transferring data and communicating between LabVIEW and another piece of software. There is a minimal amount of programming to be done in LabVIEW to open and process the data in a file, and likewise to save data to a file. One benefit inherent to this type of communication is that all data is saved before being used, so a backup copy is available if needed. LabVIEW natively supports four file types for saving and opening data: 

  1. Text File - A file with a .txt extension. The Text file contains an array of text strings, which can be parsed and read by either LabVIEW or another application. This type of file is usually accessed with word processing software, but it can be used with any tool that is able to read an array of characters. One of the advantages of a text file is that it is readable universally by many types of software packages.
  2. Binary File - A file with a .bin extension. A binary file in LabVIEW can have multiple data-types written to it, while the file itself will contain only the raw binary data. An advantage of a binary file is that there is a very low memory footprint with this file. The disadvantage is that it's not universally readable, so if the file is to be shared, there must be a reader who understands the format of the file.
  3. Spreadsheet File - A .txt file formatted as a spreadsheet. Spreadsheet formatting is the use of some type of delimiter (usually a tab constant) to indicate entries in rows and columns. This type of file format is generally associated with spreadsheet software, but can be used with any tool that is able to read and process an array of delimited text entires. Data in spreadsheets is organized into rows and columns, which makes the data easier to analyze and process.
  4. TDMS/LVM Files - Files with .tdms or .lvm extensions. These files can be either text (LVM) or binary (TDMS) files, and contain unique formatting that allows LabVIEW greater control over the data contained in the files. Third-party software can create these files through the use of a TDM dll written in C. TDMS and LVM files can be used much easier in LabVIEW than the above file formats, as LabVIEW is able to decode the files and pass the data as a Dynamic Data Type instead of a string or a number. TDMS has these additional advantages : Data can be easily searchable with the NI LabVIEW DataFinder Connectivity VIs, and the data file itself can be very large without incurring performance penalties for reading/writing, making it ideal for large amounts of streaming data.
 

Example Use-Case

One use-case of file I/O to share data between tools is using the TDMS file format to log data in LabVIEW and then perform post-test analysis of the data in DIAdem. The figure below shows the LabVIEW VIs that can be used to store simulated data in the TDMS file format. The subsequent figure then shows how DIAdem can be used to read TDMS data for advanced reporting. 


Figure 1: Storing measurement data in LabVIEW to TDMS file format



Figure 2: Reading measurement data in DIAdem
 

Using the File I/O paradigm described in this use-case, engineers can easily share data between two separate software packages.
 

Code Example

The following examples can be found from the NI Example Finder in LabVIEW, by navigating to Help->Find Examples...

  • Write Binary File.vi, Read Binary File.vi
  • Write to Text File.vi, Read from Text File.vi
  • Write TDM/TDMS File.vi, Read TDM/TDMS File.vi
  • Export Waveforms to Spreadsheet File Example.vi


TCP/IP

Description

TCP/IP is a set of communication protocols used for the Internet and other  networks. Data transfer is typically between two TCP/UDP ports across one or more IP addresses. One object typically acts as a server, and one or more objects typically act as clients. LabVIEW includes a number of VIs that allow the user to communicate across a TCP/IP network. One of the main advantages of TCP/IP is that it can be used across a variety of operating systems, since it is based off the Internet Protocol Suite and not a specific OS. One of the main disadvantages is that the user will have to modify their network security settings to allow communication to process across whatever port they choose.

The TCP protocol guarantees the safe arrival of data from the client to the server, through various methods including checksums and handshaking. The UDP protocol does not implement these reliability features, but has less overhead and thus requires less processing on either side of communication. TCP can be thought of as a connection based protocol, and UDP can be thought of as a connectionless protocol. Communication usually occurs across multiple machines over a variety of networks, but it can also occur across the same machine. This is how LabVIEW can communicate with a third-party tool.

As stated before, LabVIEW has a variety of VIs dedicated to TCP/IP communication. A third-party application would need to be able to connect to and open a TCP port so that it could receive and send data to a LabVIEW application. LabVIEW allows the user to write or read an array of characters, which can then be decoded into usable data by either LabVIEW or the third-party software. The nature of TCP/IP communication allows LabVIEW and the third-party application to stream real-time data.
 

Code Example

The following examples can be found from the NI Example Finder in LabVIEW, by navigating to Help>>Find Examples.

  • Simple Data Client.vi, Simple Data Server.vi
  • Data Client.vi, Data Server.vi
  • UDP Receiver.vi, UDP Sender.vi
 

Example Use-Case

One use-case of TCP/IP to connect two tools is the LabVIEW Model Interface Toolkit that connects LabVIEW with The MathWorks, Inc. MATLAB® and Simulink® . The diagram below shows how a TCP/IP connection can exist between the two software packages in order to run simulations with a model from MATLAB® or Simulink®, in conjunction with a user interface or data stimulus from LabVIEW.


Figure 3: Running a Simulink® Model in LabVIEW

MATLAB® and Simulink® are registered trademarks of The MathWorks, Inc.

 

The component that handles the TCP/IP connection is called the "SIT Server", which is configured by the user to seamlessly connect the two software environments. In other words, the user is not exposed to the TCP/IP underlying code. This is provided as part of the toolkit package and abstracted from the user.
 

ActiveX

Description

ActiveX is a framework that defines reusable software controls that can be used across a variety of programming languages. The ActiveX framework is based on the Windows Component Object Model, or COM, and Object Linking and Embedding, or OLE technologies. ActiveX enabled applications, such as LabVIEW, include objects that have exposed properties and methods that other applications can access. LabVIEW can act as an ActiveX client, where it can access objects of other ActiveX enabled applications, or as an ActiveX server, where other applications can access objects of LabVIEW. ActiveX objects can be a variety of things, both visible (buttons, documents, pictures, etc.) and invisible (application objects, data) to the user. LabVIEW can access a third-party application by accessing an object associated with that application, and vice versa.

When LabVIEW acts as a client, it can convert the data types of some ActiveX properties and methods into data types that LabVIEW can interpret. LabVIEW accesses an ActiveX object through the automation refnum control or the ActiveX container, both of which are visible on the front panel. These embedded objects access other ActiveX objects, and allow programmatic control of the object. With this method, LabVIEW will access your third-party program within the LabVIEW environment.

When LabVIEW acts as a server, other applications access LabVIEW's VI Server. This server interface allows client applications to programmatically access LabVIEW through the LabVIEW type library. This type library includes information about LabVIEW objects, methods, and properties. Similar to the way LabVIEW embeds ActiveX objects onto its front panel, a third-party application can also embed an ActiveX object into wherever necessary. With this method, your third-party application will access LabVIEW from within the third-party's environment.

ActiveX requires a significantly greater amount of programming to implement, and is only used with Windows operating systems. However, ActiveX enabled a much more seamless interaction between LabVIEW and another application, and also allows for real-time data transfer and analysis between those applications. It also allows the user to limit interaction to just one environment, instead of both LabVIEW and their application.
 

Code Example

The following examples can be found from the NI Example Finder in LabVIEW, by navigating to Help->Find Examples...

  • Many can be found by navigating to Communicating with External Applications >> ActiveX >> General/Word/Excel
 

Example Use-Case

The NI LabVIEW-SolidWorks Mechatronics Toolkit integrates LabVIEW, SolidWorks, NI-Motion, and COSMOSMotion together to allow the user to perform various tasks. These tasks range from performing Collision Detection on a SolidWorks model to controlling a robot. COSMOSMotion contains a number of exposed ActiveX object classes that can be accessed through LabVIEW.



Figure 4: CMOTIONRefs.ctl
 

This control's cluster can be unbundled to access individual ActiveX objects. In the image below, the CMOTION refs control is unbundled so that you can access the Mechanism object. An Invoke Node is called on the Mechanism object for DeleteSimulation, which deletes the current simulation and enables mechanism edits and new simulations.



Figure 5: ActiveX references being unbundled and accessed

 

The COSMOSMotion ActiveX Object can be used to set the properties of various things. An example of setting these properties can be found in the following two screenshots : 


Figure 6A: SW Load Motion Profile.vi


Figure 6B: SW Load Motion Profile.vi

 

The points below correspond to the points in Figure 6A and 6B:

  1. The values unbundled here are the values we would like to set our properties to. In particular, JointName, MotionType, InitialDisplacement, and InitialVelocity will all be used to change the value of an ActiveX object.
  2. The Mechanism ActiveX object is being unbundled from CMOTION refs, and a property node is inserted to extract various properties of this object. Name is being set to JointName, and elem is being extracted.
  3. Here, ActiveX dummy objects are used to convert the class variants to ActiveX Object references, which will have their own set of property and invoke nodes.
  4. The IDDMMotion ActiveX class is used to set MotionType, InitialDisplacement, and InitialVelocity
 

Command Line

Description

A command line interface provides a way to interact with a computer's operating system to perform various tasks. Command line interfaces differ across various operating systems, so for simplicity this article only describes using the Windows system-level command line. Check the documentation for your operating system for additional information on using the command line interface. LabVIEW can communicate with a third-party application by launching and executing programs through the command line.

The usefulness of the command line is found in command line arguments. Command line arguments are parameters that are passed to a program. The program can then perform specific tasks based on these arguments. Arguments are passed into the program as strings, which can be parsed and processed. Generally, an executable is called from a command line command, with the arguments appended to the command. Things such as two numbers to add can be passed in, as well as things like which mathematical operation you wish to perform on those numbers. this is all dependent on how the program is set up to respond to command line arguments. Command line communication ca be thought of as one-way communication, as one program makes a command line call to another program without being able to receive a response. 

The command line can be accessed from within LabVIEW by calling the System Exec VI. From here, any command line call that the operating system allows can be used. One useful feature of this is that programmatic calls to the command line can be made with this function, which allows for automation of the process.

Likewise, command line calls can be made with arguments for LabVIEW VIs and executables. Arguments are passed in by calling the VI or executable with two hyphens (--) separating the end of the executable call and the beginning of the arguments. These arguments can be accessed in LabVIEW through the use of a Property Node. Since the arguments are passed in as strings, string parsing and manipulation can be done to process the arguments appropriately. With the use of other Property and Invoke Nodes, an entire LabVIEW VI can be automated and ran from a simple command line command. 
 

Code Example

Developer Zone Example Program : Command Line Options in LabVIEW Executables

The following examples can be found from the NI Example Finder in LabVIEW, by navigating to Help>>Find Examples...

  • CommandLine.vi and Description.vi
  • Additional examples can be found by navigating to Programmatically Controlling VIs >> Dynamically Loading and Calling VIs
 

Example Use-Case

The CommandLine.vi LabVIEW shipping example demonstrates one useful way of using the command line. Keep in mind that command line communication is most useful when combined with another approach, such as one mentioned in this document. This example is called by entering a string similar to the following in the command line: 

"C:\LabVIEW 8.6\labview.exe" "C:\LabVIEW 8.6\examples\New Features\SimpleCommandLine.llb\CommandLine.vi" -- /number:5 /boolean:0 "/string:National Instruments"

Figure 7: Example command line call with arguments

 

This call opens LabVIEW (in this instance, version 8.6), then calls the CommandLine VI with multiple arguments inserted after the -- characters. The arguments being passed in are the number 5, the Boolean value 0, and the string "National Instruments". Note that each argument is separated by a space.



Figure 8: CommandLine.vi
 

Referring to the figure above:

  1. The command line arguments are extracted and parsed into separate strings.
  2. The strings are searched for relevant data, and that data is then extracted.
 

Comparison Of Approaches

Each approach is ranked from 1 to 5, 5 being the highest. Definition of Terms:

  • Cross-Platform - How well an application written for one operating system transfers to a different operating system. Approaches scoring high in this category do not depend on OS-based programs and code to function.
  • Complexity of Integration - The amount of work needed to implement a useful approach. Approaches scoring high in this category take a small amount of time and effort relative to other approaches.
  • Seamlessness - How well an application fits in with existing applications. Approaches scoring high in this category blur the line between where one program ends and another one begins.
  • Usability - What an approach has to offer besides simple data transfer. Approaches scoring high in this category allow the user to do more than just transfer data.
 Cross-PlatformComplexity of IntegrationSeamlessnessUsability
File I/O3512
TCP/IP5433
ActiveX1255
Command Line1542