Is there a new version of Labwindows 2023 planned?

[santo_13]

---

@mcfischer wrote:

A bit late for the party (or should I say funeral)... Given that we'll see the end of LabWindows in not too distant future, what are the options for folks who prefer an actual programming language (i.e. not LV)? I don't really care about the function panels and help (nice to have, but I can do without). I know that at least some of the drivers (DAQmx, GPIB, and such) come with a library that are C/C++ "compatible" and could be called from MS Visual Studio Code. The functions in the advanced analysis library are maybe some of the easier ones to find (not sure, though), but what about all the GUI graphs, controls, etc., tons of utilities, etc.? Did anyone make the jump yet and can share the experience?

Martin 

---

Python is on its way to be fast and robust with abundant community support. C# on the other hand is robust and a great upgraded alternative to C/C++ but it does come with a huge learning curve.

[mcfischer]

Thanks Santhosh,
The nice thing about LabWindows is (was) that I had all things in one package (access to NI drivers, GUI, viualization tools). They weren't perfect, but they were there. So let me be a bit more specific with what I was looking for. Most of my apps:

• are very data heavy (I routinely use multithreading to distribute the load onto several processors);
• involve a fairly complex GUI with tons of graphs/visualization (1D and 2D), numerical controls; and
• make heavy use of the DAQmx, IVI (VISA), IMAQdx, NI-Motion (outdated) libraries.

In principle, I'm willing to make the transition to python or C# (or stick with C/C++) but want to make sure I'm betting on the right horse. My concerns with python would be speed - not sure if I can get the same performance.

For either case, there are plenty (almost too many) choices for the GUI (Tkinter, wxPython, PyQt,… for python; WPF, Forms for C#), visualization/Graphing (MatplotLib, Seaborn, Plotly,... for python; Plotly, ScottPlot,... for C#). I really don't know how well these play together. Or how long-lived these will be. Are there any complete examples (GUI + visualiztion + DAQ/IMAQ etc) for any of these platforms?

So many questions, so many choices 😉
Thanks,
Martin

[santo_13]

---

@mcfischer wrote:

Thanks Santhosh,
The nice thing about LabWindows is (was) that I had all things in one package (access to NI drivers, GUI, viualization tools). They weren't perfect, but they were there. So let me be a bit more specific with what I was looking for. Most of my apps:

• are very data heavy (I routinely use multithreading to distribute the load onto several processors);
• involve a fairly complex GUI with tons of graphs/visualization (1D and 2D), numerical controls; and
• make heavy use of the DAQmx, IVI (VISA), IMAQdx, NI-Motion (outdated) libraries.

In principle, I'm willing to make the transition to python or C# (or stick with C/C++) but want to make sure I'm betting on the right horse. My concerns with python would be speed - not sure if I can get the same performance.

For either case, there are plenty (almost too many) choices for the GUI (Tkinter, wxPython, PyQt,… for python; WPF, Forms for C#), visualization/Graphing (MatplotLib, Seaborn, Plotly,... for python; Plotly, ScottPlot,... for C#). I really don't know how well these play together. Or how long-lived these will be. Are there any complete examples (GUI + visualiztion + DAQ/IMAQ etc) for any of these platforms?

So many questions, so many choices 😉
Thanks,
Martin

---

Python vs C#, C# will be the fastest hands down.

I would be surprised if there is a complex application using C# or Python with GUI and NI Instrument acquisition as an example out there somewhere.

But, I know of many complex, very sophisticated and reliable applications built with C# with GUI, NI Instruments and heavy data processing.

[TonyG-614]

I've been following the various discussions about the demise of CVI.  I understand there may not be a good business case for continuing development on the platform, but I think it is fraudulent to still bill customers for support.  I just received my annual auto- renewal invoice for CVI and it's $810!!!  Why would I pay them $810 if they are giving up on the tool?  How many companies are going to receive these invoices and just automatically pay them without asking the engineer using the tool if it's still being supported?  If a company is continuing to collect money for a service they know they are not going to provide, what can you call that except fraud?

TonyG

[MarcelK]

Just to add my 2ct, my company spends a six figure dollar amount every year on NI licenses for TestStand and Developer Suites. Yes, most of this is officially for TestStand BUT 95% of our absolutely essential TestStand extensions are written in CVI! If we have to give up CVI then we might as well migrate away from TestStand, too, because that's not a lot more work then and will save a lot of money in the long run.

I don't think the powers that be have any idea what effects they're causing by this "strategy" as you don't see these in the pure CVI usage statistics.

[RobertoBozzolo]

Well, it seems we'll have to address all those questions to another actor...

Emerson Electric to buy National Instruments for $8.2 bln to deepen automation push 

[rolfk]

---

@RobertoBozzolo wrote:

Well, it seems we'll have to address all those questions to another actor...

Emerson Electric to buy National Instruments for $8.2 bln to deepen automation push 

---

I'm not hopeful that Emerson sees anything in LabWindows/CVI. They do show LabVIEW in one of their slides as an addition to the Emerson offering, but even that may be just some nice board of directors presentation graphics with little meaningful substance.

[richferrara]

For whatever it's worth, there was an f3 patch of the 2020 version released a few weeks ago. Not sure if this is any indication that work on LabWindows could be continuing for a new release.

[rolfk]

It mainly means that there is still someone who knows how to look at the source code, start the build tool chain and afterwards the init test framework, check the generated reports for any indication of regressions and then build an installer package.

A new release in comparison would be a lot more effort as you also need to do real development work, lots of debugging, compile, build, test, modify cycles and last but not least generate new documentation and change existing one.

Before NI states officially what their actual plans are you should hope for the best but plan for the worst!

[paul.knight@zeroavia.com]

Coming from a Python environment back to LabWIndows after two years, I can say you can create a similar test program in Python (GUI & Instrumentation) that you can in LabWIndows.  I wouldn't recommend it, takes a lot longer.  Programs run slower.  Difficult to create an .exe.  Also, if you deploy your code as a package, the source code gets downloaded to the test computer where any one can modify it.  Python was written by someone who was bored over the Christmas break.  Dig deeper a lot of the code in the wild was written by college students getting the Master or PHD.  Very limited support from developers.