From Friday, April 19th (11:00 PM CDT) through Saturday, April 20th (2:00 PM CDT), 2024, ni.com will undergo system upgrades that may result in temporary service interruption.
We appreciate your patience as we improve our online experience.
LabVIEW
What is stopping you from switching to LabVIEW NXG? - VI server
Solved!
@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.
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 🙂
@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.
Search LabVIEW like a graph!
@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.
@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.
@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...
