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

[rolfk]

---

@mcduff wrote:

---

---

Actually never had the chance to use NXG. But this is kind of worrisome. Either NI does not have the resources to properly develop NXG or is less interested in software and more interested in hardware. Does not make me feel real confident in using LabVIEW as a development tool as its future seems in doubt.

---

That is probably a bit overzealous.

I would suspect that the reason for this decision were a number of different causes. The task of creating a completely new version of LabVIEW was definitely underestimated. And while LabVIEW still is NI's flagship software, software as a whole has been getting less important with the new company direction they are heading for.

But I also think that some people were to much believing into the .Net hype marketing, of how .Net makes everything much simpler to develop. Yes .Net is great if you want to do something simple or not so simple. Talking to a web service, no problem just grab an existing .Net library and ready you go.  Wanting to do JSON formatting, hell which of the 500 libraries should I use? Then you start to create a bigger application and start to get into the dependency hell. I need library xyz version 4.3 and library zyx version 5.3 and ... and ... and. But wait xyz 4.3 uses zyz 3.2 but zyx 5.3 uses zyz 4.5 and they are not compatible. Sh@t!

In fact the entire .Net universum looks very great and very easy if you only use a few libraries in your project. But try to get a big project working that uses umptien different libraries and you end up spending more time into tracking and resolving dependency conflicts than anything else.

Ok lets develop everything from scratch ourself then, that will solve the problem! NOT! And we are back by Joels Software link that was mentioned earlier elsewhere. 😁 Things You Should Never Do, Part I – Joel on Software

.Net is in essence still simply something very much inspired by Java. Yes it has added new language features since, that surpass several Java features but .Net was developed to be a different Java to not have to bend to the Java community (and its creators at Sun Microsystems which were not friends with the people in Redmond). If you ever tried to port a Java library to .Net or vice versa you will be surprised how much they are similar, even down to function names, but with the obligatory upper/lowercase changes to not make it look to similar!

[mcduff]

---

@rolfk wrote:

---

@mcduff wrote:

---

---

Actually never had the chance to use NXG. But this is kind of worrisome. Either NI does not have the resources to properly develop NXG or is less interested in software and more interested in hardware. Does not make me feel real confident in using LabVIEW as a development tool as its future seems in doubt.

---

That is probably a bit overzealous.

---

Maybe, but the year is 2020, stranger things have happened. 😉

Anyway talking to regional NI Reps, they say they their major customers want hardware with turn-key solutions. When said purchasers need something more specific than they go to CLAs. Python is well supported, maybe in the future, one less thing to develop if all the new users are Python people.

mcduff

[altenbach]

I think it is a great idea to breath new life into classic LabVIEW. Yes there are things that can be improved, but nothing that has been learned developing NXG will really go to waste. With LabVIEW again being the main focus, things look very bright.

The only thing I will finally update is going full LabVIEW 64bit for everything. I really doubt I still need to support a subset of users that use Windows 32bit. (This was a concern in the Windows XP&7 days but now (since spring 2020) even Microsoft no longer offers windows 10 32bit for OEM.)

(I really tried to give NXG a chance, but it was a steep uphill battle. NONE of my programs that I tried was ever successfully converted to NXG. I could have managed a few broken GVIs, but I always ended up with a project of empty files. Square one is too hard! The >2 minute launch time was also a bit tedious.)

[Mike_King]

I am glad I spent minimal time in NXG with this being abandoned essentially now. I wish NI had built more web libraries for CG instead of so much effort in NXG which took forever to even get to a basic overall level of support and for me, none of my projects were doable in NXG due to lack of features and its overall much slower environment, even giving it a good trial.  

I build a lot of my labview applications for real time and controls in LabVIEW, but most of my UIs are then done with web tools.  Primarily websocket connections and I have no UI restrictions then from LabVIEW, I can use the power of javascript and millions of great libraries and frameworks like vue.js to create brilliant UIs that LabVIEW has no chance at, nor did NXG or the web module. I use vue.js now as a framework, its absolutely fantastic (so is react) and the only thing labview still does comparatively well in the way of the UI, is graphing.

From my point above for wanting more web libraries from NI (love the http set for rest, AWS IOT I use regularly, websocket 3rd party is a must have, python tools finally, etc), I just wish they had more data connecting options for web tools, which I have had to largely build myself and still need more, I'd wish labview CG would enhance these areas to better connect with other languages and embrace what others do so well.

-More python connectors for data sharing (auto data type conversions, better arrays, structure handling, compatible file formats to use from both with the aid of a library)

-python 2 way sync modules to have auto-updating data registers in both sides, Labview and python app over sockets.

-callbacks and event registration to/from python and or javascript to better support direct messaging

-File syncing/monitoring with events triggers

-More features with websockets and multi client connections

-authentication libraries and built in tools over TCP/websocket/python connections for auth tool chains

-libraries for connectivity between these langauges with automatic encryption and security built in.

-More IOT libraries, mqtt native protocols, More big vendor support for their systems: AWS, AZURE, others with native libraries, that are actually maintained and updated more. IOT for example uses HTTP data instead of MQTT, which is more limiting and restrictive.

-Extend the concept of datasockets, but with extensible plugins, I want to publish any variable (on change or at interval) to my IOT topic for example with controllable formatting of the topic/payloads

-Libraries to easily build and have alarming systems associated with any variable, which could also extend to data connectors to output these.

-Support for various 3rd party notification frameworks like push notifications, SMS, email notifications

-Pub/Sub tools that work across labview / javascript / python with widened data type support

-data centers for configuration data (I heavily use maps feature with various datatype support for super fast data access/reference)

To me, these are the kind of tools and libraries that other languages excel at and LabVIEW isn't keeping up, but if it integrated others languages more easily, it would be far more capable. Python for data analysis, Javascript/web for much more UI work/displays, Labview for embedded and interconnected library pipelines and synchronization between them.If network like variables were built on existing supported protocols in other languages, libraries could easily extend labview to those spaces and vise versa. 

Anyway, that's my $0.02.  I guess this shift away from NXG kinda proves to me its too little too late for web with labview (which I thought 5+ yrs ago) and I'm sure glad I've invested time learning other web frameworks and tools for UI replacements so I can minimize LabVIEW use to where it is best and use other languages where they are best.

[wiebe@CARYA]

---

@rolfk wrote:

Ok lets develop everything from scratch ourself then, that will solve the problem! NOT! And we are back by Joels Software link that was mentioned earlier elsewhere. 😁 Things You Should Never Do, Part I – Joel on Software

---

That was on a private forum.

As a side note, this article was written 20 years ago, but his articles seem to keep very well over time.

[rolfk]

---

wiebe@CARYA wrote:

---

---

That was on a private forum.

---

That's not the only place this keeps getting quoted. 😁

It's as accurate nowadays as it was back when he wrote it 20 years ago. It's a trap every software developer has a leaning to fall in. Some do it once or twice, others do it over and over again. 😁

In very rare cases something beautiful comes out of that. In most cases by far, a different half finished product is the result.

[wiebe@CARYA]

---

@Mike_King wrote:

To me, these are the kind of tools and libraries that other languages excel at and LabVIEW isn't keeping up, but if it integrated others languages more easily, it would be far more capable. Python for data analysis, Javascript/web for much more UI work/displays, Labview for embedded and interconnected library pipelines and synchronization between them.If network like variables were built on existing supported protocols in other languages, libraries could easily extend labview to those spaces and vise versa. 

---

LabVIEW shouldn't keep up with those libraries. LabVIEW\NI should enable us to make those libraries. Not sure if that is what you're saying.

Some libraries that you mention are actually there (, or at least I have some you mentioned).

I feel it's actually unreasonable to expect NI to maintain libraries as well. And undesirable as well.

Fast time to market is how it seems to work, and that makes libraries like NI Vision run far behind market standard. Libraries like that, or all libraries that possibly can, should be outsourced. A community (or even a 3rd party) driven vision library would stand the test of time much better. In the meantime, NI can work on improving LabVIEW.

Ironically, NI Vision was a 3rd party library... When it was acquired, it pretty much froze.

Acquiring NI Vision made perfect sense back then. It was the way for NI to support machine vision in LabVIEW. As it is now, I think LabVIEW can carry it's own weight. Let us put the icing on the cake.

[billko]

---

@rolfk wrote:

---

wiebe@CARYA wrote:

---

---

That was on a private forum.

---

That's not the only place this keeps getting quoted. 😁

It's as accurate nowadays as it was back when he wrote it 20 years ago. It's a trap every software developer has a leaning to fall in. Some do it once or twice, others do it over and over again. 😁

In very rare cases something beautiful comes out of that. In most cases by far, a different half finished product is the result.

---

Unless a new product with its own set of unknown bugs is your goal, it's usually better to work with what you have.  It's better to have quirks you know about than quirks you don't.

[srm@viewpointusa.com]

from one of my guys but reflects my thoughts as well.

"Part of me is very puzzled. Wasn’t NXG supposed to solve many of the unsolvable problems with LV? How will they get fixed? Did NI learn enough about good software development that they are going to start applying that to LV and rewriting large portions? One of the things that makes other IDEs so powerful is the ability of the community to extend them to meet their needs. Does this mean we’ll start to get common, documented APIs for extending LV? Is the mess that is refnums going to get consolidated into a single, unified methodology? Are classes/projects/builds/packaging going to get fixed? Will they be able to move beyond Windows 95 era GUI and database technology?

Or is this a repackaging of NXG? Is LV 2021 going to be NXG with a LV skin and they pull the mask off in 5 years and go “ha, look, you were using NXG all along”?

It will be interesting to see. I hope there is more information in the near future. It would be great to see a roadmap of how they plan to “fix” LV. So many questions."

[Yamaeda]

I was so excited when I first heard about NXG. LV but with .NET and modern design and all the plugin possibilities and controls! The little I've tried it always missed some key feature, so no realy project have been made.

That being said, I do hope some of the ideas/lessons make it into LV, which as we all know have some issues (yes lvproj, I'm looking at you). I wonder how much can be imported/upgraded? You can write pure C in Visual Studio, right? Can you do it easily in a .NET project? If so, you should be able to move LV to a .NET project and slowly import the NXG function that worked well into CG.

Well, one can hope atleast.