The Future of LabVIEW for Advanced Developers

NI’s R&D team has been hard at work on a major investment into a next generation version of LabVIEW, which we were excited to finally unveil at NIWeek 2017 this past May.

For anyone who followed the launch of LabVIEW NXG 1.0, you know that the focus was on configuration-based workflows that are designed to quickly acquire and analyze data from your hardware. You can learn more about these features at, but that’s not what we’re going to discuss today.

The Future: Beyond LabVIEW NXG 1.0

LabVIEW NXG 1.0 is a first step for us in a multi-release journey that will culminate in a LabVIEW that is designed from the ground-up to better serve the needs of large-scale, complex system developers that are coordinating teams of developers.

To that end, LabVIEW NXG 2.0, which is currently in Beta, will add important features for advanced users, including object-oriented programming, an early installment of VI Server, application builder, TestStand integration, and more.

However, I want to use this forum to highlight four lesser-known, but major in-flight investments, some of which go beyond 2.0, that will be especially relevant for those of you doing software engineering with LabVIEW. We touched on a few of these items in the afternoon keynote of NIWeek – if you missed it, be sure to check out the video below:

It’s worth emphasizing that the syntax of the G language is the same in LabVIEW NXG. The nature of the investments discussed below revolve around workflows for large system developers – the fundamentals of how you design and architect your software will be unchanged. In addition to classes, new language constructs like Channel Wires will eventually be moved over.

1. Software setup and dependency management

Opening code and getting it into a runnable state can be a daunting task in any language. You need to track down all the dependencies, find the right versions, install the appropriate run-times, and be sure to put everything in the proper location – all of which can be very time consuming and error prone.

Screen Shot 2017-10-01 at 10.46.11 PM

Our investment into the use of package management for all software distribution is designed to directly address this and several other related challenges. The use of packages for installing and sharing code means that everything knows the packages it depends on, the specific versions, and where to get those dependencies from.

The primary usage-model does not require a connection to NI or the cloud – we know that you’ll want to host and manage your own repositories of software, inclusive of NI products and your own reuse libraries. NI Package Manager will also have tools to create and setup your own repository and duplicate any public feeds for internal clients. This also allows administrators to ensure that only ‘approved’ versions of software are available for use internally.

The new editor will automatically track your dependencies for distributions as you define dependencies, but this will be paired into future capabilities that will give programmers absolute control over which dependencies to reference and load. This means that you’ll be able to easily link against your version-controlled source for development and then relink to the source distribution package without reloading the entire project and moving things on disk.

Finally, we are emphasizing the importance of our the CLI for these tools from the outset, as we expect many of the associated distribution workflows to be automated into continuous integration workflows.

2. Team-based development

All the LabVIEW NXG source file formats are XML. This is a significant departure from the current binary file format, which can make integration with source code control tools problematic, though possible.

The intent of the text-based file format is to facilitate simple code reviews in text-editors and common workflows built around source code control. It also has the added benefit of enabling ‘trusted download’ procedures for anyone that must do development in classified environments, as the files can easily be audited to ensure no classified information has been included.

NI is still going to provide a graphical comparison utility, as comparing large numbers of changes in an XML format may be impractical. As with the current utility, this will be available for invocation via the command line, which is designed to enable integration with source control clients. We do not have any immediate plans for a graphical merge utility, which means that automated merge operations will need to be performed on a per-*gvi or file basis.

Another related change: the LabVIEW NXG editor will do its’ best to load unknown content from a *gvi. This means that newer code stands a good chance of being openable in older versions, though any new nodes or language constructs will obviously be shown as unknown content.

As explained in #4, investments in more easily componentizing large application hierarchies across separate libraries will also lend itself better to team-based development workflows.

3. Editor performance when manipulating large application hierarchies

Several characteristics of a project have historically impacted the LabVIEW editor’s behavior and responsiveness, but the sheer number of items and the complexity of the code are two of the most important.

There are some operations that are inescapably long, like compilation, so while we continue to invest in making these operations faster, the LabVIEW NXG editor makes it possible for us to launch background operations asynchronously that keep the user focused on their job instead of waiting.

Some of you may see elements of this in action in LabVIEW NXG 1.0 when a project’s source is available for edit before compilation is complete. This allows users to start browsing and viewing source before you can even click run. This operation will take the longest when opened on a clean machine, as it’ll need to create the initial compile cache for the project.

Another example is the generation of an executable, which will now be non-modal, meaning that you can continue to work while the build operation proceeds.

4. Componentized software architectures and deployment

A large monolithic executable is the most common built format in LabVIEW today. It works, but it has numerous drawbacks: it takes a long time to build, it’s difficult to update, and the installer for it winds up being large. Related, long-build times mean that some people find themselves waiting for hours before they discover that there was a critical error in their application source or build configuration. Oh and last but not least, rebuilding and redistributing your entire application can also trigger extensive revalidation procedures!

The solution is to move towards more componentized application structures. This helps distribute development responsibilities and the associated build operations, which makes it possible to isolate changes to the impacted component. As a result, distributing the updated component is a simple patch – just drop it in and leave everything else alone.

This approach is possible today – in fact, it was one of the first topics I wrote about at length on this blog – but it is non-trivial. One of the biggest barriers revolves round the work required to structure source in a way that it is possible and so that the binary versions can be appropriately re-linked.

However, a unique component output will be the default behavior of libraries in future versions of LabVIEW NXG. Your top-level application can generate a binary and the libraries your application depends upon will also generate their own binaries, which we are calling GLLs. Your built executable will automatically be relinked against the built GLL, so no trickery is required to get things working. Furthermore, when you hit ‘build,’ the editor will only rebuild the components of your application that have been modified, thereby decreasing the scope of change and the overall time required.

When it comes to creating installers, the binaries you generate will leverage the package technology discussed earlier to ensure that the appropriate dependencies are on their destination without having to include them all. Your patch stays small, but can still get any missing dependencies.

What About [feature I’m expecting]….???

My goal was strictly to highlight some of the larger, but lesser-known investments we’re making that will have very important implications for advanced users and people who care about software engineering for LabVIEW. To hear more about the broader set of features (get excited for web-based interfaces!), visit or sign up for an NI seminar in your area this fall!

When can I start using these features?

Many of these investments are under-the-hood and will be exposed to users when we achieve the necessary levels of robustness and UI implementation. Deep dives will follow in the coming months as these new technologies mature and we get closer to release.

We’re confident that when these advanced features are combined with the ease-of-use and approachability of some of the interactive capabilities in future versions of LabVIEW NXG, that engineers and scientists will discover a new level of unencumbered productivity and capability.

What do you think?

We know we still have a lot of work to do, but we’re very excited by this journey. On a personal note, it’s also extremely exciting to finally begin sharing the fruits of our labor over the last several years.

The input of our advanced users continues to directly guide and influence our plans, so please share any comments or questions below.

2 thoughts on “The Future of LabVIEW for Advanced Developers

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s