LabVIEW Remote Monitoring

6 ways to do remote monitoring with NI LabVIEW

In this article, we define LabVIEW remote monitoring as acquiring measurement data from a distant location (e.g., the other side of a factory, a different building, or halfway around the world) from where the data is to be analyzed/utilized. The data might simply be viewed before later use or it might be written to a database for further analytics.

So what might you want to remotely monitor and from where?

  • Test equipment on the factory floor from your office
  • Power generation equipment at some remote customer site halfway around the world
  • A product out in the field back at corporate

Since this article was originally published in 2018, NI’s support for web-based application has exploded. Some of the original methods we originally discussed, such as LabVIEW Remote Panels, have been superseded, while others, such as LabVIEW Raw TCP functions, remain.

We’ve also removed NI InsightCM, since this platform has been transferred to Cutsforth and specialized to various specific monitoring applications.

While reviewing the methods below, keep in the back of your mind how you are going to manage the datasets your remote system will be sending you. So much work has been done to SQL databases and other supporting tools since we originally wrote this article that we strongly recommend you consider using a database to help organize and manage your data.

Here are the updated 6 methods for remote monitoring with LabVIEW:

  1. Windows remote desktop
  2. Raw TCP functions in LabVIEW
  3. LabVIEW network streams
  4. LabVIEW Web Server
  5. NI WebVI – G Web development
  6. NI SystemLink

Caution: there are lots of different options (with varying degrees of completeness) to use here.  If you don’t know what you’re doing, you can end up with a non-working or at least a very error-prone application.

Windows remote desktop

What is it in a nutshell?

You can interact with a LabVIEW application that is running on a remote PC. You connect to that remote PC by using the Remote Desktop Protocol (now called Remote Desktop Connection) widely available since Windows XP.

What remote monitoring scenario is it best suited for?

If all you need to do is interact with an application and visualize graphs, remote desktop works well. However, control of this remote machine can only be done manually, just as if you were at the remote location sitting in front of the PC.

What should you know about it?

Transfer of data to another PC and control of the remote PC are manual processes. Also, the firewall configuration setup by IT may precent connecting to the remote PC.

Suggested LabVIEW Developer Level

Novice

Raw TCP functions in LabVIEW

What is it in a nutshell?

Yep, you can talk raw TCP in LabVIEW.

What remote monitoring scenario is it best suited for?

This method generally only makes sense when you want to create a custom messaging scheme on top of TCP, but with some of the other libraries available (like NI’s AMC), it’s best not to create your own unless it is required.

What should you know about it?

You’ll have a lot of control, but also a lot of opportunity to make mistakes.

Suggested LabVIEW Developer Level

Intermediate

LabVIEW Network streams

What is it in a nutshell?

A built-in method that provides a way to share data across a network. This capability is a step up from raw TCP and, while not as flexible, it is easier to use. A good overview about LabVIEW Network streams can be found on NI’s website. A very high-level explanation is also available.

What remote monitoring scenario is it best suited for?

Network streams do a good job of streaming lossless LabVIEW data from point to point over a network and is built using TCP and UDP.

What should you know about it?

This method is more accessible than raw TCP, but you’re going to have to write a lot of client/server processes. And, since this method is strongly focused on moving data, you might also perhaps want to consider having a web UI or the raw TCP functions to interact with the data sending application.

Suggested LabVIEW Developer Level

Intermediate

LabVIEW Web Server

What is it in a nutshell?

This service manages HTTP requests from LabVIEW VIs and other apps, such as written with HTML and JavaScript, to call LabVIEW VIs. The responses from those VIs need to be of a form that can be rendered by a browser or any other app that can consume the data served up by those requests.

What remote monitoring scenario is it best suited for?

Any time you wish to have a thin client on a remote PC, such as a browser, and wish to have LabVIEW VIs compose the responses.

Compared with LabVIEW WebVIs, discussed next, using the LabVIEW Web Server may be a simpler deployment and offer more flexibility, since you are closer to the raw HTTP messaging, but you have to do more development work to get to the same features that the WebVIs offer.

What should you know about it?

You’ll need to know about HTML, JavaScript, C#, and likely some of the many pre-developed libraries to build the code that creates the HTTP requests (e.g., GET method) and handles the responses.

If this approach sounds interesting, spend some 30 minutes with this overview video to learn more. Alternatively, consider working with a knowledgeable web developer to provide the web coding side of your project. With that path, this web work can be done in parallel with the LabVIEW coding and, if you’re not familiar with the web tool chain, you won’t have to educate yourself.

Suggested LabVIEW Developer Level

Advanced

LabVIEW WebVI – G Web development

What is it in a nutshell?

The G Web development application offers web development with familiar LabVIEW-like coding. At a basic level, the application builds the HTTP and JavaScript code that you’d have to write using the LabVIEW Web Server approach.

What remote monitoring scenario is it best suited for?

This approach is best applied to complicated monitoring applications or situations where you need to develop multiple web apps.

The WebVIs can interface with the LabVIEW Web Server. They also interface well with NI SystemLink, which is designed for monitoring the operational status of many machines. See below for an overview of SystemLink.

What should you know about it?

LabVIEW WebVI, also known as G Web Development on NI’s web pages, is an outgrowth of LabVIEW NXG. On some of NI’s webpages about WebVI, you may still see references to NXG, but NXG stopped being developed past 2022.

This development environment is only LabVIEW-like, and the dissimilarities with LabVIEW will require you to learn a new environment. Balance that fact against the knowledge ramp you’ll have to climb using the more basic Web Server approach.

An overview page of WebVIs on NI’s website holds additional details. And, NI has provided several examples such as using the NI Web Server and SystemLink Cloud, calling 3rd-party services like USGS data and JavaScript, and an application that uses multiple top-level VIs.

A recommendation would be to learn to do LabVIEW WebVI dev if you intend to make several web apps, since you’ll become faster at development with each additional app. You might also consider combining WebVI development with the web development environment embraced by professional web developers, which use HTML, JavaScript, C#, and so on. By combining your efforts with those of a professional web developer, you could focus on what you are good at and leave the web side to what they are good at.

Suggested LabVIEW Developer Level

Intermediate and Advanced

NI SystemLink

NI SystemLink is a platform for managing distributed systems in test and measurement. The platform is designed to remotely monitor variables from various PCs using the SystemLink UI. We’ve not familiarized ourselves extensively with SystemLink, but it may be worth looking into for applications that need to manage multiple data acquisition devices, querying and displaying device operational status, retrieving the status of the machine to which the device is connected, and transferring data to a central data store. And, it works tightly with the LabVIEW WebVI technology, so using both together may be the approach you are seeking.

What is it in a nutshell?

SystemLink is a piece of software developed by NI.  Learn more from NI here: What is SystemLink? – National Instruments.

What remote monitoring scenario is it best suited for?

SystemLink is intended for use on test and embedded applications running on NI hardware for the purpose of publishing status and operational data for remote users. SystemLink can be deployed on-premise or in the cloud.

Coupled with LabVIEW WebVIs, complex remote visualization, control, and data management is available.

What should you know about it?

SystemLink is a complex platform, the learning curve is steep. Since this article is about remote monitoring, an important aspect of SystemLink is its ability to interface with LabVIEW WebVIs (a.k.a. G Web Development) for the purpose of developing UIs for interfacing to the remote PCs.

Some interesting links to learn more are:

Suggested LabVIEW Developer Level

Intermediate, Advanced, and Expert depending on the complexity of the application

Hardware required

Of course you’ll need to connect to or create a network of some sort (or at least a point-to-point link).  Here’s some hardware that could be used to help you get connected remotely:

  1. Ethernet port & network
  2. Wi-Fi enabled device (e.g. http://www.ni.com/en-us/shop/select/c-series-wireless-gateway-module)
  3. Cellular enabled device (e.g., https://shop.sea-gmbh.com/SEA-9745-4G-Mobilfunk-Kommunikationsmodul-Kit/60000070-SEA-9745-Kit). You may need to contact your cellular provider to enable this device to connect to the cell network.
  4. Proprietary wireless communication systems for long range or high-speed communications (e.g., https://www.gegridsolutions.com/Communications/licensedSolutions.htm )

Next Steps

Once the remote, likely web-enabled, LabVIEW application is running, you will eventually want to consider the steps associated with handling all the remote data you will be accumulating. An approach that had proven itself over many decades is to use a database. The database empowers you with searching, sorting, and filtering capabilities to help you find, review, and process the selected data.

Not all raw datasets, such as large waveforms, need to reside in the database. In fact, it probably shouldn’t for reasons of database size and responsiveness. Regardless, we recommend storing at least enough baseline information to give you the means of locating all the large datasets not stored in the database that meet the query criteria.

Database design and interfacing is another whole topic not covered here. Many web developers also have skills in databases.

To learn more about LabVIEW-based remote monitoring with or without a web interface, check out these case studies:

How to get help

If you work for a US-based manufacturer, looking for help with LabVIEW-based remote monitoring and possibly data management, you can reach out here.