LabVIEW NXG - when will we start using it

[0_o]

Hi,

LV NXG got itself some new features that finally make me conceder it, more so because of the LV2018 release bugs and the fact I can't work with LV2017 along with LV8.5.

It supports DAQmx, Vision, FPGA, SVN, TestStand and much more. 

Mainly, I hate feeling left behind stuck at LV2016, especially when it comes to Python support.

However, I don't see here a thread about NXG with active users so I don't know what is not yet supported and what will be the learning curve. Will I, again, be NI's guinea pig?

I understand they have a code migration tool yet I don't know how good it is for huge projects. Is it using a VI at all? Does it support scripting and OO? Could I use llb/lvlib/lvlibp/...? What are the benefits? Is the FP resizable?

Migrating upstream is one thing. What about downgrading? Even Regular LabVIEW can't handle downgrade (just try writing a vi in 2016 with a conditional indexing tunnel and save it back to 8.5 that didn't have this feature - LV8.5 will crash).

Yours truly,

Guinea pig SN: 23145211.

Edited December 19, 2018 by 0_o

[smithd]

I have it installed, last time I tried to migrate even a small part of a shared library everything broke. I need RT support, subpanel support, I'm not looking forward to figuring out dll calls, and I rely on drjdp's json stuff which last I heard, I thought didn't work in Nxg due to how variant parsing functions changed. Now that the strings are all supposed to be unicode, it scares me a bit to upgrade any binary-based parsing so we'd need to spend time validating that. They changed VI server open VI from having an input specifying normal/call and forget/call and collect so now its hardcoded per node, which may cause failures.

Last time I tried to use it for a small, new project I gave up because it was too slow and I couldn't handle it.

Edited December 19, 2018 by smithd

[Gribo]

I am going to wait till there is one product (2020? 2021?). Right now, I am on 2015sp1, and have no real incentive to upgrade.

[smithd]

11 minutes ago, Gribo said:

I am going to wait till there is one product (2020? 2021?). Right now, I am on 2015sp1, and have no real incentive to upgrade.

Probably more like 2025 or 2030 I thought, unless you mean 'when they stop caring about current lv at all'

Edited December 19, 2018 by smithd

[drjdpowell]

They need a killer feature, some great thing not in regular LabVIEW.  So far I haven't identified such a feature.

[Neil Pate]

Killer feature: new hardware only supported on NXG 🤦‍♂️

[crossrulz]

4 hours ago, 0_o said:

Does it support scripting and OO? Could I use llb/lvlib/lvlibp/...? What are the benefits? Is the FP resizable?

Scripting is a work in progress last I heard.  OO is now a feature and NI is working on Traits.  I think llbs are gone.  lvlib I think got transformed into something else.  I do not know of any replacement currently available for the PPLs.

Benefits?  "Programming Optional"!

For me, I will consider NXG when packages (ie PPL replacement) are more fleshed out.  Otherwise, I think all of the features I would need in my current position are implemented.

[Phillip Brooks]

Killer feature: SSH 😆

[crossrulz]

24 minutes ago, Phillip Brooks said:

Killer feature: SSH 😆

I did have word that NI was working on something for SSH in LabVIEW 2019.  I have not seen anything mention of it in the beta forum (have not gotten it installed yet), so it probably got delayed.

[smithd]

I'd rather they do tls

You don't normally need ssh to be fast, so using something like this https://github.com/sshnet/SSH.NET/ or calling putty using system exec isn't a huge deal.

Edited December 20, 2018 by smithd

[JKSH]

14 hours ago, 0_o said:

It supports... FPGA...

Only for LabVIEW Communications type applications (on PXI). FPGA through RIO (and RIO in general) is not yet supported.

 

15 hours ago, 0_o said:

Mainly, I hate feeling left behind stuck at LV2016, especially when it comes to Python support.

Note that Python support is Windows-only.

I was hoping to use the Python Node on my LinuxRT cRIO, but no dice.
 

15 hours ago, 0_o said:

I don't know what is not yet supported and what will be the learning curve.

Related: http://www.ni.com/pdf/products/us/labview-roadmap.pdf

 

> Is it using a VI at all?

Yes, but the file format is different.

 

> Does it support scripting

Not yet (see Roadmap link)

 

> and OO?

Mostly. But we can't have type definitions inside classes.

 

> Could I use llb/lvlib/lvlibp/...?

• llb: Gone in NXG (which is a good thing; these are terrible for source control)
• lvlib: Yes
• lvlibp: Not sure

 

> Is the FP resizable? 

No.

 

 

9 hours ago, drjdpowell said:

They need a killer feature, some great thing not in regular LabVIEW.  So far I haven't identified such a feature.

My company finds WebVIs pretty useful. We've started using it for some real projects (but only for the web client -- we still use LabVIEW Classic for other parts of the project, including the web server)

[Mads]

Every now and then I hope for a bright future and open the latest NXG - and my head hurts. They've changed too much, and gained so little🤯.

I immediately get irritated by how disrespectful the whole thing is of the strengths of LV, but try to push myself to get more used to it. Then I hit a brick wall in a lack of functionality, and my patience runs out.

Back to LabVIEW 2018. Home sweet home☺️ (sure, the roof is leaking and the style is a bit 90's, but it beats NXG).

Edited December 20, 2018 by Mads

[drjdpowell]

2 hours ago, Mads said:

They've changed too much, and gained so little

That was my impression; changing everything for no good reason rather than retaining continuity with the past but changing a few keys things where there is real benefit.

[ShaunR]

15 hours ago, Phillip Brooks said:

Killer feature: SSH 😆

Meh. Had that for years

[Michael Aivaliotis]

I strongly suggest you don't even touch NXG.

LabVIEW 2018 has Python support if that's what you need.

[Benoit]

What about ODBC support?

I have a huge project with a superb HAL implemented. I cannot see how I can migrate that to NXG.

I feel like having 20 years of my career but on the garbage with NXG.

This is not happening with other text language where stuff change, but do not receive a huge refactoring.

I guess this is what happens with proprietary language. you use what they offer, not what people really needs.

The only good thing for now if the Unicode support.

Benoit

[smithd]

21 hours ago, Mads said:

I immediately get irritated by how disrespectful the whole thing is of the strengths of LV

 

18 hours ago, drjdpowell said:

That was my impression; changing everything for no good reason rather than retaining continuity with the past but changing a few keys things where there is real benefit.

I'm fairly curious about these statements -- is the issue a lot of small incompatibilities like the ones I mentioned, or something more major?

3 hours ago, Benoit said:

This is not happening with other text language where stuff change, but do not receive a huge refactoring.

Lol -- python

Edited December 21, 2018 by smithd

[Benoit]

Python for me is a script language not a programming language. 😉

Benoit

[ShaunR]

1 hour ago, smithd said:

With regards to the unicode thing, I think they didn't go far enough -- they should have broken everything

They didn't need to do that. All they had to do was enable the rendering of UTF8 strings and we could support unicode easily.

Edited December 21, 2018 by ShaunR

[Benoit]

I think the biggest mistake from NI was to not add 20 years experienced user into their development team. I believe they only put marketing people and some developer... but no real user.

Benoit

[smithd]

4 hours ago, ShaunR said:

They didn't need to do that. All they had to do was enable the rendering of UTF8 strings and we could support unicode easily.

Woops, I decided to kill off my rant but I guess you were already responding.

I guess you're right, but I'd like to revise my comment -- I don't want to have to flip back and forth between byte arrays and strings. I want to be able to index characters out of strings, and I want to be able to search for a subset within a byte array, etc. The shift towards saying all strings are unicode without enhancing the features associated with binary byte array seems like a mistake.

Edited December 21, 2018 by smithd

[bbean]

6 hours ago, Benoit said:

I think the biggest mistake from NI was to not add 20 years experienced user into their development team....... but no real user.

Benoit

This.

I tested NXG for the first time at a feedback session during the CLA summit.  So I was learning NXG on the spot in front of one of the NXG developers.  When I would get stuck trying to figure it something out, the developer would ask how would you do that in legacy LabVIEW and I would tell him, then he would show me how to do it in NXG.  My understanding was that the NXG IDE was designed to make the number of programming number steps more "efficient".  Unfortunately this sometimes sacrifices the many years of muscle memory doing things in legacy LabVIEW.    A bad analogy would be brushing your teeth with the opposite hand because studies have shown that ambidextrous tooth brushers clean teeth slightly better.  It may be slightly better in theory but the pain of learning outweighs the benefits.   Some of the things I remember being slightly different (annoyingly):

• Quickdrop functionality
• Adding a terminal on the block diagram seemed more tedious and defaulted to not showing the Control/Indicator on the front panel  . WTF.

While I'm sure the NXG team has received guidance/direction/development/feedback from very experienced insiders at NI, I walked away feeling like there was no way the internal NI experienced LabVIEW users were developing only with NXG on a daily basis by default.  Otherwise muscle memory things like quickdrop would work exactly like they did in legacy LabVIEW.  I think what needs to happen is Darren needs to un-retire from fastest LabVIEW competition and compete next May at NI-Week using NXG. 

That said the NXG developers and team leads were very receptive to my feedback and seemed genuinely open to making changes.  Now whether that carries through to the end product or not we will see.  I also saw some new IDE features (new right click options for instance) that made me think that makes sense and I can see that helping speed up development once I get used to it.

If and when I use NXG I would like to see a checkbox in the options that says "maintain legacy front panel, block diagram and keyboard shortcut behavior as much as possible"

 

[ShaunR]

4 hours ago, bbean said:

My understanding was that the NXG IDE was designed to make the number of programming number steps more "efficient".  

I've said it before and I'll say it again. Speed of laying down primitives/controls is a non sequitur. It even pales in comparison to the time spent making sure wires were straight and non-overlapping (which I find oddly relaxing). I estimate that as little as 10% of my programming time is actually placing VIs, controls, primitives et. al. Another 10% aligning controls and wires and the other 80% is iterating, refining, debugging and documenting.

Making a whole new ide because it is "more efficient" is an excuse you use to management and sales to fund your project when you have no concrete arguments. The real reason, IMO is more to do with that people are so afraid of touching the existing LabVIEW code and they have a glut of .NET coders who suffer from "not invented here" syndrome.

I'm banking on that by the time they get anywhere near parity with the proper LabVIEW, I will have retired and won't have to use it.

Edited December 21, 2018 by ShaunR

[Rolf Kalbermatter]

On 12/19/2018 at 9:26 PM, crossrulz said:

I did have word that NI was working on something for SSH in LabVIEW 2019.  I have not seen anything mention of it in the beta forum (have not gotten it installed yet), so it probably got delayed.

No. The developer blames his new borns colics for that 😀. But from what I understood it doesn't consists of such a difficult thing as it was supposed to be using pling. Technically it's quite simple, the challenge lays in the fact to make it work on all LabVIEW platforms, including RT, which is mainly a serious amount of testing and testing and testing again.

Quote

I've said it before and I'll say it again. Speed of laying down primitives/controls is a non sequitur. It even pales in comparison to the time spent making sure wires were straight and non-overlapping (which I find oddly relaxing). I estimate that as little as 10% of my programming time is actually placing VIs, controls, primitives et. al. Another 10% aligning controls and wires and the other 80% is iterating, refining, debugging and documenting.

Making a whole new ide because it is "more efficient" is an excuse you use to management and sales to fund your project when you have no concrete arguments. The real reason, IMO is more to do with that people are so afraid of touching the existing LabVIEW code and they have a glut of .NET coders who suffer from "not invented here" syndrome.

I'm banking on that by the time they get anywhere near parity with the proper LabVIEW, I will have retired and won't have to use it.

I feel similar about NXG. Lots of change for often pretty vague reason. There was one point about the old LabVIEW code base, it did contain some very ugly code, a lot of it originally caused by the fact that the C compilers at that time struggled to compile the LabVIEW code base at all. Apple repeatedly had to increase the symbol table space in the C compiler in order to allow NI to compile LabVIEW. That resulted in some code that is probably almost unmaintainable. Still, I don't know if throwing the baby out with the bath water was such a good idea to fix this. A more modular rewrite of variaous code parts of LabVIEW might have been easier and develivered similar results, and left classic LabVIEW not out in the cold for new features as has happend for almost 10 years now.

And as far as the new MDI style GUI goes, I simply hate it.  And the loss of multiplatform support is another big minus.

Quote

Note that Python support is Windows-only.

I was hoping to use the Python Node on my LinuxRT cRIO, but no dice.

I was under the impression that it did work in LabVIEW for Mac too. But no hard evidence for that.

Quote

What about ODBC support?

I'm not quite sure what that has to do with LabVIEW NXG or not. ODBC is not something that even LabVIEW Classic supports in any way out of the box. Sure there used to be the one Database Toolkit that was using ODBC and then got bought by NI and redisigned to use ADO instead of ODBC to interface to databases.  So are you rather asking about database access in general, independent of ODBC in special? If so that should be one thing where NXG is actually easier as it makes access to .Net APIs simpler. And the .Net database API is all that you need to interface to most databases. Maybe not as trivial as installing the database toolkit and be done, but definitely much easier than many other things you can think up. If you really specifically talk about ODBC support then you shouldn't expect that from NI. ODBC is an old legacy technology that even Microsoft would like to forget if they could.

Edited December 21, 2018 by Rolf Kalbermatter

[smithd]

7 hours ago, bbean said:

•  
• Adding a terminal on the block diagram seemed more tedious and defaulted to not showing the Control/Indicator on the front panel  . WTF.

Dunno if this is the same time frame, but I vaguely remember that early on they seemed to be saying "our users complain about absurd right click menus, therefore -- no more right click menus!". That seems...better in 3.0, although I honestly still can't remember which icon is which. I actually like that the terminals don't show up by default. After all, 99% of your code doesn't need a UI. 

Also, I dunno about you but I'm going to accidentally close so many windows. I'm used to ctrl+w'ing twice as many times.

3 hours ago, ShaunR said:

Another 10% aligning controls and wires and the other 80% is iterating, refining, debugging and documenting. Making a whole new ide because it is "more efficient" is an excuse you use to management and sales to fund your project when you have no concrete arguments. The real reason, IMO is more to do with that people are so afraid of touching the existing LabVIEW code and they have a glut of .NET coders who suffer from "not invented here" syndrome.

Yeah, I've always been under the impression was that NXG was for NI's efficiency, not users (directly). They wanted to try to provide tools that make the debugging and documenting and editing easier, but the 20 year old codebase was hindering them in doing so. The reason is likely along the lines of what you said, although its probably a bit simpler: reading code is hard. 

43 minutes ago, Rolf Kalbermatter said:

ODBC is an old legacy technology that even Microsoft would like to forget if they could.

 

Poor microsoft, they can never forget 👻

Edited December 21, 2018 by smithd