Community Browser
Showing results for 
Search instead for 
Did you mean: 

Re: Why Two Versions of LabVIEW?

Active Participant

Since we announced LabVIEW NXG 1.0 and LabVIEW 2017 at NIWeek 2017, I’ve found myself answering a handful of questions again and again. The most common relates to why we didn’t just release LabVIEW NXG along-side a new version of the traditional LabVIEW environment, but instead committed to an ongoing set of investments in both versions of LabVIEW. The answer is quite complex, but in a beautifully simple way.


It boils down to three key reasons:


There is No Better Way to Guarantee Your Continued Success


Enabling our users to effectively maintain their software applications over time is a core principle of NI. We’re committed to making sure that you’re confident in the decision to move to LabVIEW NXG, when the time comes.


Let’s address the elephant. LabVIEW NXG 1.0 does not contain all the functionality that’s in LabVIEW 2017. For example, LabVIEW NXG does not yet support CompactRIO. LabVIEW NXG does not yet have functionality for classes, application deployment, or TestStand integration. You can find a detailed comparison here.


We did an extensive amount of research into other vendors who have executed this scale of a platform migration. The most common point of failure for the users was that they felt forced the upgrade. Even if LabVIEW NXG were complete enough for the entire LabVIEW user base, a clear majority of you would need an elongated timeframe to determine the most appropriate time to move a developed code base over into a “new LabVIEW.”


We’re committed to empowering you to make that decision based on your considerations: project timelines, infrastructure upgrades, and the evolving needs of the system. We have, and will, continue to invest in the current versions of LabVIEW to ensure you can choose for yourself. This investment will include support for new hardware, continued investment in performance and stability, and novel software capabilities.


The Capabilities in LabVIEW NXG 1.0 Serve a Segment of Our User Base


Most existing LabVIEW users scoff at the “programming optional” positioning for LabVIEW NXG. I’ve heard several versions of a comment that sounds like the following – “LabVIEW is a powerful programming tool and I use it to do <insert hard thing> which requires programming and can’t be met by a non-programming solution.”


My response to that is a thunderous and roaring applause. I completely agree. The release of LabVIEW NXG doesn’t diminish the amazing things that you’re doing with LabVIEW. It doesn’t make it less impressive, doesn’t make you less of an engineer, doesn’t mean LabVIEW 2017 isn’t the most powerful engineering system design software in the market. It is. LabVIEW 2017 is the most powerful engineering system design software in the market, on the planet, or in any other solar system. I can’t be sure of the last one, but I’m confident.


LabVIEW NXG 1.0 introduces new non-programming workflows that are designed to minimize the time from sensor connections to engineering insight. Just like LabVIEW 2017, LabVIEW NXG is designed for engineering systems that require rapid measurements from hardware. The key difference is that the workflow inside of LabVIEW NXG gets you MUCH further down the path to the complete system than LabVIEW 2017 does. The interactive panels for acquiring measurements, capturing data, and designing analysis routines not only provide a methodology for doing so with point-and-click simplicity, but also designs the code behind the scenes that can be dragged and dropped onto to Diagram.


Image 1.png


Yes, I know we had that with Express VIs. Yes, I know we had that with SignalExpress. But, let’s be real. The code generated in both of those scenarios is not….good. It’s not good.


LabVIEW NXG provides a path to measurement automation for engineers and scientists that don’t like to, or know how to, program.


LabVIEW NXG isn’t an “OR”


LabVIEW NXG is the future of LabVIEW, but the present is the unique combination of both LabVIEW NXG and LabVIEW 2017. Many of the features in LabVIEW NXG are designed to complement existing deployed applications without migrating or moving code forward. Let’s explore two examples.


LabVIEW 2017 includes the ability to author packages. Packages are an industry-standard concept for installing and distributing software. Packages, along with libraries, go hand-in-hand for creating modular and scalable software, which makes building large software applications even easier. Ultimately, we want everyone creating packages, so we made the ability to author packages readily available in LabVIEW 2017.


LabVIEW NXG 2.0 will introduce a feature called WebVIs. WebVIs enable you to build rich Web-based measurement interfaces without hiring a Web developer. The interface will include HTML5 controls and the ability to edit the HTML source directly. They can be deployed to any browser, on any device, with zero plug-ins or install. This means you can use LabVIEW NXG to build a web-based UI that can display data published to it from any existing LabVIEW application.


Image 2.png 

When it comes to LabVIEW, we’re not tying your hands with the tyranny of the or. Instead, we’re empowering you with the genius of the and.


Have confidence in LabVIEW as we move forward. You will continue to see new features, new hardware support, and improved performance in new versions of both LabVIEW and LabVIEW NXG.

Jeffrey P.
LabVIEW Product Management
National Instruments

The concept of LabVIEW NXG ist genious,

i'm looking foreward to LabVIEW NXG 2.0

best regards

et (Ernst T.)



LabVIEW NXG 1.0 looks like a re-branding of Signal Express.

 I love this comment

"Yes, I know we had that with Express VIs. Yes, I know we had that with SignalExpress. But, let’s be real. The code generated in both of those scenarios is not….good. It’s not good."


I wonder what the Signal Express press release said at the time......