LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

What is stopping you from switching to LabVIEW NXG? - VI server

Highlighted

I have this earworm every time I read this thread.

 

Spoiler

Every [LabVIEW version]

Has its ups and downs
Sometime ups
Outnumber the downs
But [yet] not in [NXG]

 

In the end of the movie, things are better.

 

0 Kudos
Message 41 of 52
(577 Views)
Highlighted

wiebe@CARYA wrote:

NXG might (we'll have to wait and see) provide a *much* better version experience. The xml files and the modularity (native functions seem to be separated from the IDE) might enable easier forward and backward version compatibility.


Last I heard, there were plans to make NXG "epics", where all of the versions inside of that epic could easily convert between.  But that has been a few years since I heard that discussed.  I really hope that is in the pipeline.


GCentral
There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines
Message 42 of 52
(562 Views)
Highlighted

@crossrulz wrote:


Last I heard, there were plans to make NXG "epics", where all of the versions inside of that epic could easily convert between.  But that has been a few years since I heard that discussed.  I really hope that is in the pipeline.


Maybe they were talking about "epochs", which can refer to a division of time.

That would be nice, although it seems like all of the compatible versions would not be able to have very big changes between them. 

0 Kudos
Message 43 of 52
(515 Views)
Highlighted

Because of the separation of the IDE and functions (that isn't there in CG) the sky is the limit.

 

When a new version of NXG adds IDE features (tools, like QD or SCC tooling), this won't effect the code. So this would not backwards cause incompatibility. These could be released as add-ons to older versions.

 

When a new version of NXG adds new functions (to the "G" language, like maps or sets), (in a lot of cases) this functionality could be added to older versions. The RTE needs to support them, but if the library breaks down the functionality to low enough level (LLVM), the RTE wouldn't need extra functionality. The new functions would simply run on the old RTE. Alternatively, the RTE could support a plug in structure as well, supporting dlls added by new features that where not needed when the RTE version was released.

 

So potentially, new features could be released almost like libraries. If a VI needs some feature, package manager could potentially 'just' download it. I quoted 'just', because it won't be that easy.

 

If each feature had a minimal required version, a VI could be saved with the highest minimal required version. So this would make the VI version independent of the used LabVIEW version altogether. The file formatting of a gvi certainly supports this.

 

All this is potentially possible in CG, but as the code base is rigid from the 30 years of development, it will be much harder. So much harder, NI started NXG.

 

Just dreaming out loud.

0 Kudos
Message 44 of 52
(491 Views)
Highlighted

@antony.g wrote:

I have a bit of a fight keeping LabVIEW going, the software team would prefer me to use Python.


 

we even have been tinkering around with LabView 2019 64Bit, because of some python x64-only libraries 

I really like that NXG is said to be 64Bit

 

0 Kudos
Message 45 of 52
(482 Views)
Highlighted

@alexderjuengere wrote:

@antony.g wrote:

I have a bit of a fight keeping LabVIEW going, the software team would prefer me to use Python.


we even have been tinkering around with LabView 2019 64Bit, because of some python x64-only libraries 

I really like that NXG is said to be 64Bit


So what is the benefit of NXG over CG 64-bit?

 

I actually see that (NXG being exclusively 64-bit) as a missed opportunity. .NET doesn't care about bitness, it's bytecode that is executed (very efficiently), not compiled code. It's just that the LV RTE is still the old, compiled one. And the VIs are being compiled. If the VIs would be compiled to .NET assembly (a switch of the LLVM backend), and the RTE was converted, NXG would run on any target supporting .NET. Any OS, any CPU, any bitness... Potentially even without recompiling. In a perfect world of course. But the .NET framework is evolving to make this possible...

 

The switch to .NET framework, with the fixed CPU feels like getting the worse of Bytecode (slower) and compiled code (fixed target) to me.

 

I'm hoping that this is just a choice to get NXG off the ground, and that eventually NXG will only require .NET Core. No restrictions on CPU or OS.

0 Kudos
Message 46 of 52
(479 Views)
Highlighted

Update: in my company I’m the guy that try LabVIEW new things first. I have being playing with NXG for about 7 months. During this time I have been writing little programs exploring the new environment. So many difficulties came out that I created a spreadsheet with 5 columns: “characteristic”, “classic”, “NXG”, “NXG workaround” and “observations”. There are already 95 items, some of then from NI online documentation. The vast majority are NXG disadvantages or drawbacks. In version 4.0 the documentation is still poor and cumbersome. Today I would only use NXG on a real project if there was an imposition from the client. I hope in a near future this table gets more to NXG side and we naturally tend to use NXG in some cases. With all it’s “defects” I still like classic much more than NXG.

André Manzolli

Mechanical Engineer
Certified LabVIEW Developer - CLD
LabVIEW Champion
Curitiba - PR - Brazil
Message 47 of 52
(406 Views)
Highlighted

@Manzolli wrote:

With all it’s “defects” I still like classic much more than NXG.


No argument there. I've not met anyone who prefers NXG. Some newbies seem to start using it 'by default' though. But they just don't know better 😁. I still feel this will change, so like you, I will keep watching NXG, so I don't wake up one day being a relic.

Message 48 of 52
(389 Views)
Highlighted

wiebe@CARYA wrote:

@Manzolli wrote:

With all it’s “defects” I still like classic much more than NXG.


No argument there. I've not met anyone who prefers NXG. Some newbies seem to start using it 'by default' though. But they just don't know better 😁. I still feel this will change, so like you, I will keep watching NXG, so I don't wake up one day being a relic.


This happened to some people working at the same institute as me last week - our IT department referred them to me following questions about driver (un)availability, but it seemed that they had installed NXG believing it to be the natural choice, current version, etc etc. 

 

Somewhat amusingly to me, they had then moved to LabVIEW 2018 because they felt using the "newest" version is generally unsafe. This might have been based on some previous experience with an older LabVIEW release - not sure...

 

I'm also not sure if this is the intended behaviour from NI's point of view (the installer certainly seems to force you to install NXG, you need to read a little carefully to avoid installing it if you only want LabVIEW 'classic', at least in 2018. I think I got 2019 directly from NIPM?)

 

Perhaps the messaging/targeting could be improved? Although as I said, maybe the desired outcome is people installing NXG without knowing otherwise.


GCentral
Message 49 of 52
(228 Views)
Highlighted

The principle of sufficient reason. I don't switch because, basing on user's feedbacks, I can't see an NXG's improvement that overcomes LabVIEW limits. Moreover, I don't want throw into junk many years of reusable code.

When LabVIEW will no more maintained, I'll consider to switch from LV to some other languages. Not necessarily NXG, (for me) at present C++ is in pole position.

0 Kudos
Message 50 of 52
(175 Views)