Community Browser
cancel
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
Comments
Member

The concept of LabVIEW NXG ist genious,

i'm looking foreward to LabVIEW NXG 2.0

best regards

et (Ernst T.)

 

Member

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......

Member

"Good ideia" make an additional version and add a new dependence on .NET framework. Now we wait a few hours longer to install measurement cards drivers and LabView NXG with .NET framework.

Member

IMHO it would have been a much better investment of time to update the LabVIEW toolkits to support the 64 bit version of LabVIEW.  It's only been 12 years since Windows went 64 bit.  

Member

NXG is a bold and brave move for transitioning.  Undeniably, the NXG interface and Front Panel UIs are much more modern.  As a heavy NI cRIO user, I do hope that LV/NXG toolkits will in 64bits in the near future.

Active Participant

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. 

Here is the question that NI should answer - when has automatically generated code ever been good (take a look at any program converting one language to another including the FPGA toolbox's generate VHDL functionality)?

 

And I wish that I could kudo the comment on 64-bit above more than once.  If NXG follows the path that 64-bit development has laid, then I suspect it will be about 20 y before we have something usable here.  I don't know how many times I have had to tell everyday users not to install 64-bit at all as it is simply just hamstrung.  Looks like I will be saying the same thing about NXG now too.

Active Participant

@dcamp and @cirrusio

 

I hear your comments and completing the LabVIEW 20xx portfolio for 64-bit support is important. To date, we've  been prioritizing this work based on demand and opportunity within our existing users. You will continue to see new add-ons be 64-bit as we move forward. 

 

As a point of clarification, LabVIEW NXG is 64-bit only. Any new functionality in the core product or included in add-ons will be native 64-bit. 

Jeffrey P.
LabVIEW Product Management
National Instruments
Active Participant
As a point of clarification, LabVIEW NXG is 64-bit only. Any new functionality in the core product or included in add-ons will be native 64-bit. 

Well I have to say, that is the best news I've heard about NXG since it was announced.  I had been wondering about the status of toolkits (e.g. Advanced Signal Processing) with NXG, but it seems those are in the plans.  There has been no word however on the Vision Development Module - what are the plans for that in regards to NXG?

Active Participant

Let me introduce you to your new best friend. We put together a web page that contains two things:

  1. A detailed comparison table of the current version of LabVIEW 20xx, the current version of LabVIEW NXG, and the functionality expected in the next version of LabVIEW NXG. You can see what's planned for 2.0 (and available today in the Software Technology Preview). To your specific point, the Vision Development Module is currently planned for 2.0.
  2. A LabVIEW NXG roadmap

You can find the page here. We will be updating this page with each release. 

Jeffrey P.
LabVIEW Product Management
National Instruments
Active Participant

Excellent!  I'd seen that page but never noticed it had a Software tab.  Thanks.

Member

cirrusio
Here is the question that NI should answer - when has automatically generated code ever been good (take a look at any program converting one language to another including the FPGA toolbox's generate VHDL functionality)?

 

Do you imply that LabVIEW FPGA should not even exist as a tool?

 

LabVIEW FPGA is meant for systems too big to be done by VHDL and/or Verilog.  Systems with multiple, tens, or even hundreds of FPGAs.

In our use cases LabVIEW FPGA produces what matters, an FPGA that does the job.  It also allows for development time to be shortened by 2-3 times.

I have also taught the tool to many who have worked on really complex systems where those cases require such a tool.

 

Have you used LabVIEW FPGA before?

 

Stepping back, your statement implies that human generated code is always better than machine generated.  Is all the human code you come across super efficient?

 

Note that: efficiency comes in many forms, speed of development, speed of execution, memory usage, etc.

 


Certified LabVIEW Architect, Certified Professional Instructor, LabVIEW FPGA expert
ALE Consultants
Active Participant

 Terry,

This is such a profoundly bad misreading of what I said that I have to wonder if it is intentional.  Firstly, it is totally tangential.  If you want to know whether I have ever used FPGA feel free to go back through my 700+ posts to find the keyword FPGA - I think you will find the answer there (hint - the answer is extensively).  

 

Working off the top of my head, I thought I recalled functionality to convert a diagram to VHDL; looks like I was mistaken. C'est la vie.  It doesn't really take away from the larger point which is automatically generated code usually isn't that great (look at code generated by Fortran to C converters for a good example of this).  

 

The key word that you seem to be missing here is automatically generated- i.e. machine algorithms (developed by people) determine how exactly to generate code based on inputs from you.  I am assuming that you actually write your own LV FPGA code.  Maybe when you create your project you use the Create New LabVIEW FPGA Project dialog option.  But this doesn't automatically generate any significant code for you.  If you do anything non-trivial, the likelihood is that you wouldn't even consider using an algorithm to generate code is slim to none.

And so this gets back to the larger point - is the investment in time that NI is putting into making it easier to get up and measuring using machine generated code a worthwhile investment for the majority of LV users?  I for one don't use Signal Express or any of the express VIs currently (and I wasn't psyched about them when they came out with 7).  And I don't know any others, beginning programmers or otherwise, who do.  Now, I have consulted with those who have been advised by NI AE or a representative to use these to get started and almost without fail it was not a good fit simply because the AE or rep did not understand scope of the problem (often because the customer didn't either).

 

Now, getting back to the praise of FPGA - yes, LV FPGA is a wonderful tool for us normies who don't have the time to invest in learning VHDL and signal processing properly.  That being said, there is still room for improvement.  Nothing wrong with that - NI has continually improved on these tools (I can remember when fixed-point math was not available in the FPGA suite).  But, maybe NI should focus on improving these toolboxes rather than trying to develop a new UI with the look and feel of Visual Studio (which I feel is a terrible fit for LabVIEW IMHO).  The whole point of my comment was to emphasize that I don't think this is the right direction to focus energy, not that LV FPGA is terrible.

 

And that is that.

 

cirrus

Member

cirrusio,

Not intentional for sure.  I appreciate your answers to my questions.

 

To your main point, I think the redesign of LV was needed.  Granted this takes away from improvements that I too like to see in tools such as LV FPGA.  One of the main things in NXG that I really like is that VIs are XML files.

Two versions of LabVIEW is certainly with its challenges.  It reminds me when NI came out with DAQmx.  Both DAQ drivers were supported for a time and at some point NI had to cut support of the old DAQ driver.


Certified LabVIEW Architect, Certified Professional Instructor, LabVIEW FPGA expert
ALE Consultants
Active Participant

I'm very appreciative of the commentary and discussion. 

 

Bringing LabVIEW NXG 1.0 to market before it was "complete" relative to LabVIEW 20xx was a difficult decision. We weighed the pros and cons many times, discussing with nearly every group across our company.

 

Ultimately, the work we did with the Customer Advisory Board and global testing with true prospects proved out that there was value in the 1.0, particularly for "new to LabVIEW" engineers and scientists. We focused the messaging on the "programming optional" workflow to put an emphasis on that. 

 

I've had conversations with many long-time users whose sentiment is "LabVIEW NXG" isn't for me. The reality is that LabVIEW NXG 1.0 isn't for them, but LabVIEW NXG will be. We've tried to be very explicit with users that you shouldn't move everything over to LabVIEW NXG yet. The release schedule for LabVIEW NXG isn't what you're accustomed to - you'll see a lot of features within each release. LabVIEW NXG 2.0 will contain (always subject to change pending schedules and work) classes, the ability to build and deploy web-based UIs, building and deploying executables, and the introduction of SystemDesigner. 

 

I'm excited to hear broad feedback from the user base on 2.0. 

Jeffrey P.
LabVIEW Product Management
National Instruments
Member

Engineers don't want to connect panels, engineers don't want to use wires. They think that work is for the technicians. I spend a lot of time teaching Antenna, RF, Microelectronics Engineers how to use LabView - every time they say: So, in Matlab this is easy... so engineers want to use formulas, but software engineers will continue to make software with LabView.

Active Participant

Terry,

Interesting comment about VIs - this will be awesome for version control purposes (was just thinking that it would be great if VIs were like classes, libraries and projects but wasn't sure if it would even be feasible).  That being said, still not excited about the UI as I have seen it - looks too confining for my tastes.  And I can't recall the reason for bumping from trad DAQ to DAQmx, but I suspect they were running into performance issues?  It's not clear to me what issues associated with the UI that NI is trying to resolve here so for me the UI changes are a big meh.  But, maybe this will all become clearer in the next several years.  Right now, NXG will not be something I will even have on my machine as it would just be taking up space (similar to LV64).

cirrus

Knight of NI

cirrusio,

Some of the UI things will save a lot of time.  Specifically, I am referring to the properties pane always there on the right.  I actually really like the 5 pixel grid that everything must conform to, eliminating stupid wire bends.  But I am with you on the rounding off and lower contrast.  But the UI is just a small part of what NXG actually is.  NGX is a ground-up development in order for NI to do the things they just couldn't do with the 30 year old core code that nobody wanted to touch.  I expect some really neat things in the next 5 years that were just pipe dreams in classic LabVIEW.  But as it stands now, even NXG 2.0 will have some big limitations for me to move to it.


There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines

The discussions from the Advanced User Track is not over. Join in the conversation: 2016 Advanced Users Track
Member

A lot of times the features that marketing highlights are not the ones that are really big hits among the users (NI isn't the only one that does this).  VIs being XML is definitely one of those.

I will not use NXG until there is OOP and FPGA support.  I installed it to play around with it.

 

From what I recall, Traditional DAQ was 16 bit, not multi-threaded, and cumbersome (grew too quickly).  DAQmx is 32 bit and much easier to use.

 

At a talk at NI Week 2017 a speaker from NI mentioned that that graphics engine for LabVIEW classic was a much older one (I forget the name) and now they are using a current.  Besides adding zoom (something I personally do not need but many ask about it) I think the new graphics engine is important because some of these things are a matter of time before Windows stops supporting them and it gives LV more capabilities.

 


Certified LabVIEW Architect, Certified Professional Instructor, LabVIEW FPGA expert
ALE Consultants
Active Participant

Thanks, crossrulz.  I am just being curmudgeonly about this.  Redeveloping the core I am down with .  But, I have been hearing about the coming of NXG now for a couple of years and based on the road map that I saw at NI Week last year, it looks like we are several years out before we have something that is of production value for most of the core users.  So my question is - why?  Why is this being rolled out now and why are we expending energy even considering this when for all intensive purposes it is just a very early beta (alpha?)?  For years, NI has had a beta program associated with new LV releases that you could sign up for if you had a strong desire to test the functionality of the package; why is NXG so different that it is being rolled out to a broad audience as a production ready package?

 

Again - I can get excited about a lot of the new functionality (although I will go ahead and say that I am not excited about UI).  But, following the release and lack of support for products like Linux distros, Mac and even 64-bit Windows, the best I can do for now is acknowledge that NXG is here with a shrug.  Maybe in 5 y this will be mindblowing, but for now I don't want to see the continued development of LV fall off to put energy into this.

Active Participant

(the forum platform is one of the reasons I am not super excited about NXG - no markdown support is cumbersome and it looks like they just made it flashier while retaining the burden of using the mouse like MS Office products or writing in HTML; kinda how I envision the LV NXG UI)

 

Besides adding zoom (something I personally do not need but many ask about it) I think the new graphics engine is important because some of these things are a matter of time before Windows stops supporting them and it gives LV more capabilities.

 

LV is not a video game.  It shouldn't be using Unreal or Unity or whatever so I am not sure what is meant by graphics engines.   Maybe you are referring to GDI, Directx or OpenGL?  These have all been around for a long time with GDI being the oldest and it seems that there is currently no threat of deprecation.  So, at best this is a red herring?   Personally, I could care less about the graphics - this is more of a marketing issue.  I just want it to be comfortable to use - and this is provided by the functionality of the UI (such as quickdrop).

Knight of NI

cirrusio said: "But, following the release and lack of support for products like Linux distros, Mac and even 64-bit Windows, the best I can do for now is acknowledge that NXG is here with a shrug."

 

NGX is 64-bit ONLY.  It is 32-bit Windows that will not be supported.  Which I consider not an issue since I have not seen anybody use a 32-bit OS in years.

 

The biggest change in the graphics is from bit-map based to vector based.  This makes it smaller (hard drive space) and more efficient.  Whatever engines were being used, I do not know nor care.


There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines

The discussions from the Advanced User Track is not over. Join in the conversation: 2016 Advanced Users Track
Active Participant

Whatever engines were being used, I do not know nor care.

Yup

> NGX is 64-bit ONLY.  It is 32-bit Windows that will not be supported.  Which I consider not an issue since I have not seen anybody use a 32-bit OS in years.

Lucky you.  My point here is that there has been a notable lack of support with regards to other OS structures (I run LV in VMs on a Linux machine so I would loooovvvvee - did I say love? - to see better support for this) so why do I have any reason to get excited about this?  None of these projects is fully developed - how will NXG be any different? (truth is, given the time line, the jury is still out; and it will be out for some time)

Member

I have been using LabView Software and National Instruments Hardware for 3 decades now.  Since 1997 we have invested tens of thousands of dollars in National Instruments hardware and software.  Most of this is installed in research facilities from Mountain View California, to Seven Sisters Falls, Manitoba, to Vancouver, BC.   

 

So, I am a little concerned when I hear something new is coming that will replace LabView.  When I took the online “Assessment”, the result was that

 

“LabVIEW NXG isn't quite ready for your application because the 1.0 release doesn't yet support the software features your project requires. NI recommends you use LabVIEW 2017 for your next project.”

 

So, I’m glad that NI is continuing to offer NXG + LV, for now.   I only hope that they continue to provide something for engineers who have ALREADY committed to a design investment based on LabView.  We invested extra money for quality because we trusted that investment to receive support for a long time to come. 

Active Participant

Jeffrey_P wrote:

 

 

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. 

 


cirrusio said: "Here is the question that NI should answer - when has automatically generated code ever been good"

 

I agree that right clicking on an Express VI and selecting to open its front panel (therefore converting it into a regular VI) resulted in code that was not pretty and sometimes not efficient either. However IMHO there are examples of automatically generated code in LabVIEW when using LabVIEW scripting that work quite well. Just to mention a few:

 

  • DAQmx Assistant Express VI has a right click menu option to generate a DAQmx Task or DAQmx Code. The DAQmx code is generated using LabVIEW scripting and generates only the code needed, nothing more, nothing less. The code is pretty decent and efficient.
  • NI GOOP Development Suite toolkit (a.k.a as GDS, formerly known as Endevo toolkit or Symbio toolkit) generates classes springboard code from UML diagram. The code generated is pretty decent too.
  • Delacor Queued Message Handler toolkit (DQMH) (tooting our own horn here) generates complete libraries and event code using scripting code and we continue to hear how much LabVIEW Developers like the code generated. 

We are waiting anxiously for LabVIEW NXG to support LabVIEW scripting, because we believe that automatically generated code can be good and can be a huge assistant to all levels of proficiency.

Certified LabVIEW Architect * Certified Professional Instructor * LabVIEW Champion
Member

Absolutly not a marketing specialist, so here is in a funny way what I would have done about NXG :

 

1) Work in my batcave in an total secret. Release NXG as a big surprise.

 

2) Work the needed time to release a 1.0 version full of everything (toolkits, etc...).

 

3) Work the needed time to release a very stable 1.0 version.

 

In my rigid developer mind, it is the price to pay for credibility and reputation.

Sébastien
CLA, CTD