Showing results for 
Search instead for 
Did you mean: 

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


@MrJackHamilton wrote:


Notifiers, Queues, BlueTooth. OLE, DDE, .NET., The XY Data to Graph VI, Traditional DAQ to DAQmx, FOR Loop not executing at all on '0' index.

Honorable Mention to: Scared Variables, Sad Engine

While I'm also not to enthusiastic about many of the choices made when deciding to go NXG I have trouble to understand this part. It sounds like you name all these things as a bad example of something in LabVIEW. I totally fail to see why Notifiers or Queues are bad.


Also Bluetooth as provided by LabVIEW was not bad in itself. The bad thing was that the Bluetooth standard didn't quite lend itself to the paradigme that you are used to from interfaces like VISA. There wasn't to much to be done from NI about this lack of instrumentation control focus from the Bluetooth consortium. The interests in that consortium were simply very different and therefore the standard moved into a direction hat wasn't really ideal for PC control. This resulted in a fragmented driver implementation that made it hard to provide a common interface and BLE simply made this even worse as by now nobody trusted into anybody to come up with a common driver interface standard anymore. BLE wasn't a key technology for Microsoft so they didn't care to much and the other players all wanted to define their own API standard and expected everybody else to follow them.


DDE was a Microsoft standard mostly abandoned by Microsoft itself as OLE was the RIGHT thing to use instead, except that when they came out with .Net, OLE was suddenly legacy technology too. You can't blame NI for providing an interface to a technology that the creator of that technology later obsoleted.


As to Traditional DAQ vs DAQmx, well that was not a seamless transition yes, but only two API standards in a timeframe of over 30 years of development is a feat that not many others have managed to provide. Traditional DAQ was developed at a time where PCs weren't even able to run a windowed OS, with DAQ hardware that had very limited performance and OS architectures where even an application had the possibility to directly access hardware register. After 15 years of carrying on and building new features into the existing framework it got simply to expensive to keep trying to support new OSes and hardware boards without creating some compatibility issues, so there was a decision to develop a new and more modular driver framework and that required also a substantially different user application interface. If anything, DAQmx is substantially easier to use and more consistent in its functionality than the old tranditional DAQ interface ever was. Things like trying to program timers or hardware timed digital IO were a lot more complicated in traditional DAQ and trying to synchronize different hardware tasks on a common sample or scan clock was an exercise in trial and error and inconsistencies between different hardware boards. The underlaying architecture was so complex that adding a new board or a new feature was almost certain to break something else in the first attempt and fixing that added new complexity every time, making the next addition of a new board even more complex.


The For loop not executing on empty indexed array input can bite you, but it is simply doing what that feature promisses to do. That this might not be what you like, is not a LabVIEW feature but something you have in every language in some ways. Maybe they should have added a Clippy anymation that asks you everytime you connect an array as autoindexing input to a loop: "Are you sure you want to do that? This could go bad if that array is empty!" 😀


As to Shared Variables, while I never really used them simply for the fact that I don't quite like big black boxes that I have no idea about how they work, they do actually work and I have seen working applications that were completely build around them as basic building block. There are problems with them such as deployment and version control as you start extending certain elements of a distributed application, but I would bet that most people wouldn't be able to implement a better architecture on their own that allows easy configuration, adaption and modification of parts of a distributed system without breaking the whole thing almost every time they change something. For single self contained applications there is nothing inherently bad about shared variables.

Rolf Kalbermatter
Averna BV
Message 21 of 52

I read somewhere that NXG does not support the cRIO platform, so I am still using LabView.

0 Kudos
Message 22 of 52

Well I finally downloaded and installed NXG 4.0 and gave it a go with a medium sized project (~1000 VIs).

I used the "code conversion utility" and it produced over 2000 problems that I had to either accept the reduced functionality, implement a work-around, or verify the conversion hasn't changed the intended functionality.


Item types listed in the conversion report...



There's a few show-stoppers in there.  I spent about an hour looking through some of the items reported by the code conversion utility and quickly realized that there is a LOOOONG way to go before I can switch to NXG.


Even if there was a way to handle each of these (2000+) reported items it would take months to go through them all and then verify the functionality.


So to answer my original question: Q. What is stopping [me] from switching...?

A. NXG isn't ready yet.  It still has a long way to go.


I have to say though, the NI Package Manager is now very useful for identifying and downloading dependencies and Add-Ons etc. (If you can get it past your organization's proxy.🙄)

Troy - CLD "If a hammer is the only tool you have, everything starts to look like a nail." ~ Maslow/Kaplan - Law of the instrument
0 Kudos
Message 23 of 52

I'm in the same boat with a lot of others. Generally I don't mind being an early adopter of a new technology/program/etc, but with NXG I haven't seen it being able to do something that standard LV can't do. Whether that's true or not I don't know- maybe I just haven't seen the right promotional materials. At the moment, LV NXG looks like "diet LabVIEW" that contains fewer features and no major new ones. I've heard they have some plans for some QOL enhancements in NXG, but nothing game-changing.


That said, a company like NI doesn't just up and make a whole parallel language for nothing, so I'm excited to see what the future holds. I'm sure they have some good stuff going on under the hood 🙂

Message 24 of 52

Hey Rolf!,

To clarify. Queues and Notifiers are awesome - can't live without them. I do recall the Notifiers out-of-the-gate had some issues. Queues were done right, still work and are the back bone of any LV code with looking at. [It's odd that no other languages don't have Queues]


Bluetooth: Agree, the standard was not standard or no fault of NI. Much like how USB got out of control, because there was a hardware standard, but no consistent software implementation standard. So everyone rolled their own digital protocol over USB.


DAQmx is one of the best things about LV. Traditional DAQ worked, but required a lot of deep code mojo.


DDE, OLE and .NET were 'keeping up with the Microsoft' ...I am merely pointing out adding support for standards is transient, and not from NI's desire, but because this is the way of things.


For Loop Index=0, was really a poke how the first implementation of the FOR loop should have behaved that way. That oversight was compounded by changing it mid-stream. 😉


Shared Variables work well, provided you don't actually use them outside of the example code. I loved the idea, used them, but we had to break up because they didn't show up for diner dates on time. It could be improved, if you could open the black box and tweak the server. Once it gets confused, you can only reboot the system. With an compiled LV application and an embedded cRIO system application using them breaks - it is impossible to debug. One says it's connected, the other says it's of them is lying to you!...It makes it hard on the relationship.


As I write this, what underlies approaching NXG and any new interface, is what surprises it has in store. Once a feature burns me, I walk away and don't look back (mostly). I have a good long-term, mutually beneficial relationship with LabVIEW...we've had our rough patches...but she means well, and I love her all the more...she's made me work hard and respect what she can do for me. Together we've been through a lot and we've accomplished many wonderful things.


Happy Valentines day LabVIEW!

xo Jack

0 Kudos
Message 25 of 52


I'm sure a 'real' programmer in Python can sort those error codes for you. I notice they are not in alphabetical order, or prioritized.


1,000 Vi's!....Dude you need a couple of wide-screen could've have crammed that code on one diagram!...ever consider the 'Stacked Sequence Structure'?.


[All in fun of course]


Jack Hamilton


0 Kudos
Message 26 of 52

@MrJackHamilton wrote:

What's jarring about slash-and-burn old LabVIEW over NXG is having been using LabVIEW since the year started with a '1'.

You mean the century (%Y) or the decennium (%y)? 🤔


I've been at it since 1999, too.

0 Kudos
Message 27 of 52

@rajatsewal wrote:

I read somewhere that NXG does not support the cRIO platform, so I am still using LabView.

It will, soon.


NXG is LabVIEW. The 'current' version is referred to as LabVIEW CG.

0 Kudos
Message 28 of 52

@BertMcMahan wrote:

I'm in the same boat with a lot of others. Generally I don't mind being an early adopter of a new technology/program/etc, but with NXG I haven't seen it being able to do something that standard LV can't do. Whether that's true or not I don't know- maybe I just haven't seen the right promotional materials.

There are some very interesting features NXG will have already (although rough around the edges), and CG will never have.


+ Custom controls

+ WebVIs

+ A text based file format

+ Unicode

+ A transparent plug-in architecture (custom functions, custom tools, even custom diagrams)


At some point, NXG will catch up on the things that are missing, but those extra features will still be there. It does need more time.


The highly flexible .NET architecture might actually allow us (at some point, with enough determination) to replace that silly MDI "keyhole view" and make it look more like CG.


@BertMcMahan wrote:

That said, a company like NI doesn't just up and make a whole parallel language for nothing, so I'm excited to see what the future holds. I'm sure they have some good stuff going on under the hood 🙂

It's not a new language.


LabVIEW CG and LabVIEW NXG are both editors for the "G" language.


If you program Python, you wouldn't say you're programming a new language if you where forced to use Notepad, in stead of IDLE? And NXG is evolving, while notepad isn't ever going to do anything for Python.


Without spending more than a few hours in NXG 2.0 (that didn't even support classes, IIRC), I could make a parent class, two children implementing different functions and a composite child in 15 minutes. That is comparable with CG: I did not need to learn a new language.


Go to a try out hands-on session, with an open mind. It might surprise you.


I can't use NXG for project, and converting CG code is even further away (and might never happen). But I'm sure there is a point (in the near future, 1-3 years at most) where I will switch. Because I want to, not because I have to.

0 Kudos
Message 29 of 52

@MrJackHamilton wrote:

[It's odd that no other languages don't have Queues]

You mean besides C, C++, Java and Python? Just to name a few...

0 Kudos
Message 30 of 52