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 48
(258 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 48
(243 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 48
(196 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 48
(172 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 48
(163 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 48
(159 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 48
(86 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 48
(69 Views)