From Friday, April 19th (11:00 PM CDT) through Saturday, April 20th (2:00 PM CDT), 2024, ni.com will undergo system upgrades that may result in temporary service interruption.

We appreciate your patience as we improve our online experience.

LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

LabVIEW subscription model for 2022

Solved!
Go to solution

Hi Billko

 

I set the references to a global variable and use that across a project's subVIs. Works fine.

 

Regards Deon

Message 541 of 748
(2,260 Views)

@JimB. wrote:

@TiTou wrote:

The question it raises in my mind is : has NI been too ambitious with NXG?


I don't know if too ambitious is the right description, but I think it's safe to say that mistakes were made considering that NXG didn't get much love from established users and was canceled two years ago.


NXG had promise.  NI killed it by their decision-making long before they had officially decided to cancel it. They did the classic "Send a few execs and marketers into a backroom to decide what the customers want and then we'll send the engineers to go build that. Once it's done then we'll ask for feedback. Of course, it will be too late to change anything, but we'll say we tried." Classic waterfall thinking and a great example of why it doesn't work. 

The easy thing to point to that illustrates this is that they were so proud that they recreated scripting (in C#) and were so taken aback and surprised that anyone would want to do scripting in LabVIEW. I mean why would you want to use LabVIEW instead of C#? Talk about not understanding your audience! That should have been immediately obvious.


They also underestimated how many people were using RealTime and how critical it was to their projects. Without RT support anyone doing realtime was never going to adopt NXG. I think maybe they got there at the end?, but it was too late

 

I point to scripting because that is the one thing that would have allowed us as a community to help them out and smooth out the rough edges. There were always going to be things that were missing from NXG. With scripting, we could have fixed that. Without scripting those just became barriers to adoption.

Which brings me to the other reason for the downfall of NXG, they were never going to even come close to feature parity while they were still adding features to OG LabVIEW. If you are going to do a rewrite, you gotta freeze the legacy codebase. You can fix bugs and security issues, but adding new features, that's just shooting yourself in the foot. If you are going to do that you might as well admit it's over and can the rewrite right then, because you've already lost.

Sam Taggart
CLA, CPI, CTD, LabVIEW Champion
DQMH Trusted Advisor
Read about my thoughts on Software Development at sasworkshops.com/blog
GCentral
Message 542 of 748
(2,177 Views)

@Taggart wrote:


NXG had promise.  ... Once it's done then we'll ask for feedback. Of course, it will be too late to change anything, but we'll say we tried." 


I've heard a few people at NI that would disagree.  I've heard some say that one of the failures of NXG, was bringing in the outside opinions too early.  Saying the public should have been brought in once a mostly feature complete version was available, and then make changes.  The first version of NXG I got to use had a ribbon interface at the top.  The sooner a decision can be made to change that, the better.  Decisions around the runtime engine, and IDE UI elements, were seemingly cemented before a public alpha was available. 

 

I actually lost a bet because of this.  I didn't realize how the IDE was basically Windows only, without huge changes.  Not knowing this I made a bet that one year after NXG 1.0 was released, there would be a Mac version.  I thought this because I figured LabVIEW was still used on Mac.  That and Jeff K. was a Mac guy.  Turns out I lost that bet badly and it would never come.  Mac support has appeared to continue to drop, with changes like the M1 Mac complicating things.

Message 543 of 748
(2,162 Views)

@Taggart wrote:

Which brings me to the other reason for the downfall of NXG, they were never going to even come close to feature parity while they were still adding features to OG LabVIEW. If you are going to do a rewrite, you gotta freeze the legacy codebase. You can fix bugs and security issues, but adding new features, that's just shooting yourself in the foot. If you are going to do that you might as well admit it's over and can the rewrite right then, because you've already lost.

I didn't get the impression that they were actually adding really anything substantial in the releases between 2013 and 2017. It was maybe WebServices in 2013, definitely not the new version and bitness specific icons in 2014, although you might count the release of 64-bit versions for Mac and Linux as a substantial development. 

 

Mostly they added fairly small improvements such as adding new Vis to the standard palette that were available in one way or the other before, some editor improvements like adding white space to a diagram and such things. Nothing that was a fundamental new development. And freezing LabVIEW classic at that point would have been a definitive fiasco since they knew that NXG won't really be ready for a few years. If they had completely done that we would most likely have searched for alternatives back then already. I never saw much in NXG to be honest, and the fact that it was going to be Windows only didn't help for me. Yes they said they kept the possibility of cross platform open but with the entire IDE going to be built on .Net that chance was about 0.1% back then as there was no viable path (and in fact even with .Net Core still isn't) to have an application like LabVIEW running on non Windows. And with every additional year only investing on a Windows version that chance grew smaller and smaller, as there were various things built into that were difficult to impossible to port to other platforms.

 

So while we agree that NXG was not well planned and carried out and the difficulties were vastly underestimated, I'm not buying that keeping at least the appearance of still updating LabVIEW Classic did add a significant effect to the failure of NXG. Rather we would likely not using LabVIEW at all nowadays! NXG at no point during its existence was a viable replacement as far as I'm concerned.

Rolf Kalbermatter
My Blog
Message 544 of 748
(2,130 Views)

I never used NXG but was quite excited about the potential future after talking to a NI rep. Before NXG beta was released, the rep stated the new version of LabVIEW would be similar to the communications suite. It would have the ability to have snippets of C-code interspersed with LabVIEW code, along with other programing languages. That ability was useful when working with modelers who coded in those languages.

 

Now I think the future for NI will be providing wrappers for Python for their hardware. Python already has an extensive library of math, vision, machine learning, etc, that will be impossible for LabVIEW to compete with. Plus everyone is learning it college. It was fun while it lasted.

Message 545 of 748
(2,006 Views)

I tried NXG and found several features quite useful, so I used it on a simple job, coded on site for a customer.  It was unable to make an executable.  Several calls back and forth to NI with no resolution, I had to rewrite the code in LabVIEW. Eventually they solved the executable problem, and I tried a more ambitious project, that revealed that the platform was half baked and riddled defective or missing featueres common in it's predecessor.  I don't think I spent more than 60 hours trying make NXG useful, before giving up. The assumption was that it would be better to adopt early, than play catch up.  Yup.. Mistake.

Message 546 of 748
(1,979 Views)

Maybe 2013-2016, but 2017 brought vims. 2019 brought sets and maps. 2020 brought interfaces. Those were kind of the nails in the coffin.

Sam Taggart
CLA, CPI, CTD, LabVIEW Champion
DQMH Trusted Advisor
Read about my thoughts on Software Development at sasworkshops.com/blog
GCentral
Message 547 of 748
(1,919 Views)

@Taggart wrote:

Maybe 2013-2016, but 2017 brought vims. 2019 brought sets and maps. 2020 brought interfaces. Those were kind of the nails in the coffin.


For you maybe. Not for me. NXG had never a chance to be a viable option for me and pretty much any project in our company. No Realtime and cRIO support simple were the first KO. Building a 1000 VI application the next. Trying to port minor code and fatally failing another. And MDI for me was a choice that I only had accepted with a gun pointing at my head. And people were starting to consider abandoning  LabVIEW altogether as things like new icons being touted as a great feature pretty much were hilarious at best. And the rest were minor bugfixes and improvements. And it was getting more and more obvious that even NXG 6.0 won’t be able to do all of the things LabVIEW could do since version 7.x, some 17 years ago. Maybe those improvements to LabVIEW were a little nail in the coffin but NXG was already on IC life support and barely surviving.

Rolf Kalbermatter
My Blog
Message 548 of 748
(1,902 Views)

@Taggart wrote:

Maybe 2013-2016, but 2017 brought vims. 2019 brought sets and maps. 2020 brought interfaces. Those were kind of the nails in the coffin.


I just wanted to add my list of features in various LabVIEW editions.  NI likely wants to have one major feature to talk about to get people excited.  I certainly don't care about all of these things, but they are things NI wants to talk about in each version.

 

  • 2012 - Loop Tunnel improvements with concatenating, conditional, indexing, and last value / Project Templates
  • 2013 - Improved Web Services / WebDav / SMTP / Bookmark Manager
  • 2014 - Actor Framework (I might be off by a version or two) / 64 bit Mac and Linux support
  • 2015 - Custom Right Click Framework
  • 2016 - Channel Wires
  • 2017 - VIMs / Forward Compatible Runtime 
  • 2018 - Command Line Interface / Python integration / Type Specialized Structure for Improved VIMs
  • 2019 - Sets and Maps
  • 2020 - Interfaces for classes / Free Community Edition with Application Builder
  • 2021 - SFTP, Updated Python for 3.6 through 3.9, Call MATLAB code
  • 2022 Q3 - Improved Python and MATLAB support, initial support for toolkits independant of LabVIEW version.
Message 549 of 748
(1,776 Views)

@rolfk wrote:

@Taggart wrote:

Maybe 2013-2016, but 2017 brought vims. 2019 brought sets and maps. 2020 brought interfaces. Those were kind of the nails in the coffin.


For you maybe. Not for me. NXG had never a chance to be a viable option for me and pretty much any project in our company. No Realtime and cRIO support simple were the first KO. Building a 1000 VI application the next. Trying to port minor code and fatally failing another. And MDI for me was a choice that I only had accepted with a gun pointing at my head. And people were starting to consider abandoning  LabVIEW altogether as things like new icons being touted as a great feature pretty much were hilarious at best. And the rest were minor bugfixes and improvements. And it was getting more and more obvious that even NXG 6.0 won’t be able to do all of the things LabVIEW could do since version 7.x, some 17 years ago. Maybe those improvements to LabVIEW were a little nail in the coffin but NXG was already on IC life support and barely surviving.


 

Well you don't nail the coffin until you've already put the dead body in it.

Sam Taggart
CLA, CPI, CTD, LabVIEW Champion
DQMH Trusted Advisor
Read about my thoughts on Software Development at sasworkshops.com/blog
GCentral
Message 550 of 748
(1,705 Views)