NI abandons future LabVIEW NXG development

[hooovahh]

Don't worry Brian will pick up the tab.

[ShaunR]

1 hour ago, brian said:

They'd want to spend the time to make it presentable to people without flashlights.

 

1 hour ago, brian said:

XControls, anyone?

Oh. that reminds me. I really should clean up this xcontrol (the toolbars).

I've also got a Tab Control one too, if anyone is interested.

[X___]

3 hours ago, brian said:

XControls, anyone?

More seriously, Jeff's vision is for more of LabVIEW to be written in LabVIEW, with the intent that it empowers users like us to extend it.

LabVIEW doesn't have to be open source to do that, and my optimism comes from the possibility that the R&D team is going to have more resources to increase extensibility.

Sure, why not rewrite Linux or Android in LabVIEW too... 🙂

XControls are not standard LV objects. Can't put them in array, they have all kinds of limitations, and while I understand that they were created at great cost and with the best intentions, they essentially failed (I think I have developed one and concluded that this was not worth the effort - in large part because of the impossibility to array them).

I'd say pessimism seems warranted after the failure of NXG and the complete lack of a clear roadmap (this is what I was referring to with the term quixotic - with a typo).

I have since cut NI some slack and understood that little guys like me are of no monetary values to them. Fair enough and in any case, this is not the type of programming language I can publish code in since it is hieroglyphics to most. And even that at some point will have no value, as we will just tell Alexa the general features we need in our software, maybe draw a GUI mock-up and a DL network will generate the code...

[brian]

2 minutes ago, X___ said:

XControls are not standard LV objects. Can't put them in array, they have all kinds of limitations, and while I understand that they were created at great cost and with the best intentions

"at great cost"?  I don't think so.  They are pretty hackish.

Would you put Channel Wires in the same boat?  They are not intrinsic, built-in objects, either.  Malleable VIs, Classes, Interfaces? Most of the dialogs?  Also built in LabVIEW.

[X___]

 

3 hours ago, brian said:

"at great cost"?  I don't think so.  They are pretty hackish.

Would you put Channel Wires in the same boat?  They are not intrinsic, built-in objects, either.  Malleable VIs, Classes, Interfaces? Most of the dialogs?  Also built in LabVIEW.

That may explain things then.

I am not a channel wire convert, use VIM occasionally and have stayed clear from classes (and thus interfaces). Which I guess excludes me from the conversation?

Some dialogs are obviously LabVIEW-built, and have aged pretty badly. The GSW is a recent example of accelerated obsolescence.

But as far as I know, the universal answer to requests and suggestions has been: "NI has other priorities and limited resources". How could it be otherwise indeed? Maybe, just maybe, tapping in a free multiplier of resources could change things? It is not that there are only negative examples out there of open source programming language development... But I'd understand that a scalded cat fears cold water.

[LogMAN]

I don't really expect many new language features or UX improvements in LabVIEW just because they stop working on NXG.

From what we know there are only a few knowledgeable people at NI who are intimately familiar with the codebase and some of its intricate details which fundamentally drive LabVIEW. There are also many customers who rely on that technology for their own business. Because of that, NI can't just throw more developers at it and change LabVIEW fundamentally unless they find a way to stay compatible or take a bold step and do breaking changes (which are inevitable in my opinion).

LabVIEW will probably stay what it is today and only receive (arguably exciting) new features that NI will leverage from the NXG codebase to drive their business. Unfortunately NI hasn't explained their long-term strategy (I'll assume for now that they are still debating on it). In particular what LabVIEW/G will be in the future.

• Will it be community-driven?
• Will it be a language that anyone can use to do anything?
• Will it be the means to drive hardware sales for NI and partners?
• Will it be a separate product altogether, independent of NI hardware and technology?

There are also a lot of technology-related topics they need to address.

• Does LabVIEW Support Unicode? - National Instruments
• Comparing Two VIs in LabVIEW - National Instruments (ni.com)
• Error 1316 While Using .NET Methods in LabVIEW - National Instruments (ni.com)
• Using NULL Values or Pointers in LabVIEW - National Instruments (ni.com)

Not to forget UX. The list is endless and entirely different for any one of us. If and when these will be addressed is unknown.

Don't get me wrong, I'm very excited and enthusiastic about LabVIEW and what we can do with it. My applications are driven by technology that other programming languages simply can't compete with. Scalability is through the roof. Need to write some data to text file? Sure, no problem. Drive the next space rocket, land rover, turbine engine, etc.? Here is your VI. The clarity of code is exceptional (unless you favor spaghetti). The only problem I have with it is the fact that it is tied to a company that want's to drive hardware sales.

[X___]

7 hours ago, LogMAN said:

My applications are driven by technology that other programming languages simply can't compete with. Scalability is through the roof. Need to write some data to text file? Sure, no problem. Drive the next space rocket, land rover, turbine engine, etc.? Here is your VI. The clarity of code is exceptional (unless you favor spaghetti). The only problem I have with it is the fact that it is tied to a company that want's to drive hardware sales.

I wouldn't use a language which is based on a lot of inaccessible C++ code for mission critical software... like driving a space rocket, for instance. I have encountered a lot of "corner cases" in the math routines which had probably some trivial algorithmic flaws at their core, but this was not possible to detect (let alone correct) until I drove the code in the ground, so to speak.

One more reason to open the belly of the beast.

[ShaunR]

8 hours ago, LogMAN said:

There are also a lot of technology-related topics they need to address.

• Does LabVIEW Support Unicode? - National Instruments
• Comparing Two VIs in LabVIEW - National Instruments (ni.com)
• Error 1316 While Using .NET Methods in LabVIEW - National Instruments (ni.com)
• Using NULL Values or Pointers in LabVIEW - National Instruments (ni.com)

Unicode, as I outlined earlier, is the only thing in that list that needs to be prioritised.

Comparing 2 VI's in LabVIEW becomes moot if they switch to XML (as I also outlined). .NET can go hang - it's not cross platform - and we can already pass NuLL pointers, it's just not a LabVIEW type.

[LogMAN]

1 hour ago, X___ said:

I wouldn't use a language which is based on a lot of inaccessible C++ code for mission critical software... like driving a space rocket, for instance.

Unless you work entirely on Linux and OSS, most of the core libraries are closed source. Even if that was not the case, you still need to trust the hardware. That's why it's important to test your mission critical software (and hardware) before you put it in the field. No amount of open source will make your software more secure or reliable. You only get to fix bugs yourself and be responsible for it.

To be fair, most of us are probably not doing rocket science... right?

52 minutes ago, ShaunR said:

.NET can go hang - it's not cross platform -

"There will be just one .NET going forward, and you will be able to use it to target Windows, Linux, macOS, iOS, Android, tvOS, watchOS and WebAssembly and more." - Introducing .NET 5 | .NET Blog (microsoft.com)

52 minutes ago, ShaunR said:

and we can already pass NuLL pointers, it's just not a LabVIEW type.

 

Pointers yes, values no. If you raise a .NET Event with a NULL value, the .NET Event Callback will not fire... 

Edited December 11, 2020 by LogMAN

[MarkCG]

On 12/8/2020 at 7:48 PM, Maciej Kolosko said:

If NI would consider unlocking the ability use NI FPGA with the ability to deploy to non NI Hardware ... I think this is where G absolutely would take off like wildfire and be used on millions of IoT devices everywhere in the world that are powered by and ARM7 + FPGA module... but as it stands now if you use NI FPGA you must deploy on a target you've purchased from NI.

I would love to see NI do this. It would open up a huge new field of application for LabVIEW. I thought NI couldn't do this because of their agreement with Xilinx, to prevent NI from taking over Xilinx programming tools' share of the market. It would be a real chance for LabVIEW to survive and thrive.

[Metroid9]

Maciej Kolosko said in his reply to my earlier query that python is really taking of for applications. I completely agree with that, being a python user myself. However, he also said that a NI's LabVIEW and other products are failing due to the high price of FPGAs and what not. He mentioned raspberry pi and other iot projects as direct competitors to NI HW. But isn't G able to run on various iot projects like raspberry pi? If it is, a few good modules from NI for those iot projects could make G a great way to program iot projects.

[crossrulz]

18 hours ago, MarkCG said:

I would love to see NI do this. It would open up a huge new field of application for LabVIEW. I thought NI couldn't do this because of their agreement with Xilinx, to prevent NI from taking over Xilinx programming tools' share of the market. It would be a real chance for LabVIEW to survive and thrive.

Not quite what you are asking for, but...LabVIEW FPGA IP Export Utility

[X___]

1 hour ago, crossrulz said:

Not quite what you are asking for, but...LabVIEW FPGA IP Export Utility

Online shopping for this product is currently unavailable?

[Rolf Kalbermatter]

5 hours ago, X___ said:

Online shopping for this product is currently unavailable?

It's back online. Probably some maintenance work on the servers.

[Rolf Kalbermatter]

21 hours ago, Metroid9 said:

Maciej Kolosko said in his reply to my earlier query that python is really taking of for applications. I completely agree with that, being a python user myself. However, he also said that a NI's LabVIEW and other products are failing due to the high price of FPGAs and what not. He mentioned raspberry pi and other iot projects as direct competitors to NI HW. But isn't G able to run on various iot projects like raspberry pi? If it is, a few good modules from NI for those iot projects could make G a great way to program iot projects.

LabVIEW Community Edition (or your Professional License with the Linx Toolkit installed) can be deployed to Raspberry Pi and BeagleBone Black boards. It's still a bit of rough ride sometimes and the installations seems to sometimes fail for certain people for unclear reason, but it exists and can be used.

[X___]

39 minutes ago, Rolf Kalbermatter said:

It's back online. Probably some maintenance work on the servers.

Not if you select VHDL

[Rolf Kalbermatter]

16 hours ago, X___ said:

Not if you select VHDL

That could be because it’s not available (and never may be). VHDL sounds like a good idea, until you try to really use it. While it generally works as long as you stay within a single provider, it starts to fall apart as soon as you try to use the generated VHDL from one tool in another tool. Version differences is one reason, predefined library functions another. With the netlist format you know you’ll have to run the result through some conversion utility that you often have to script yourself. VHDL gives many users the false impression that it is a fully featured lingua franca for all hardware IP tools. Understandable if you believe the marketing hype but far from the reality.

Edited December 13, 2020 by Rolf Kalbermatter

[X___]

4 hours ago, Rolf Kalbermatter said:

That could be because it’s not available (and never may be). VHDL sounds like a good idea, until you try to really use it. While it generally works as long as you stay within a single provider, it starts to fall apart as soon as you try to use the generated VHDL from one tool in another tool. Version differences is one reason, predefined library functions another. With the netlist format you know you’ll have to run the result through some conversion utility that you often have to script yourself. VHDL gives many users the false impression that it is a fully featured lingua franca for all hardware IP tools. Understandable if you believe the marketing hype but far from the reality.

One more of those dead links on NI's website then... and no information whatsoever.

Strangely enough, I never got a "We'd love to hear your feedback" pop-up on that page. 🙂

[Maciej Kolosko]

On 12/12/2020 at 9:09 AM, crossrulz said:

Not quite what you are asking for, but...LabVIEW FPGA IP Export Utility

Thanks for that, this is definitely worth investigating on my end. I will give it a go. I managed to find a download link to this utility on ni.com. I have not tried yet, but I think it might be included in the SSP package. Looks like this could potentially work for my use case of Prototype on NI - FPGA on a SBRio and deploy on a ZynQ for mass production. 

This is not quite what I was asking for but if it works well it could be a viable option.

Thanks!

[X___]

More on this saga, picked by chance in a Forums thread (https://forums.ni.com/t5/LabVIEW/Save-the-progams-user-interface-as-picture-or-serve-it-as-a-web/m-p/4106252?profile.language=en

Future of Web Module

In essence, the loop is looped and we are back to LabVIEW Web UI, released what, 10 years ago?

The roadmap is pretty unclear past 2021...

[LeeH]

I think the biggest problem for NI with updating Labview has been the same problem faced by most developers/companies looking for a long term strategy in the last 10 years - it has been very difficult to pick a platform/technology that you believe will stand the test of time. It was a strange decision to rely on WPF for NXG but from what I remember the decision was made because other alternatives were not 'native enough', in the meantime Microsoft have had a similar platform meltdown of their own with WPF/UWP/WinUI , so as of 2020 'native' in Windows means literally nothing with Windows 10 a mishmash of every technology going and apps likewise.

For what it's worth I think the best strategy for labview in the near term is:

• A cross-platform back end (presumably they are already had/have this with CG?)
• A front end with bindings to multiple GUI technologies
• Python support, particularly for dynamic runtime scripting

I appreciate that the front end IDE will be tricky but moving this out to another technology (could be integrated somehow into the labview IDE) would not be the end of the world.

[Rolf Kalbermatter]

4 hours ago, LeeH said:

I think the biggest problem for NI with updating Labview has been the same problem faced by most developers/companies looking for a long term strategy in the last 10 years - it has been very difficult to pick a platform/technology that you believe will stand the test of time. It was a strange decision to rely on WPF for NXG but from what I remember the decision was made because other alternatives were not 'native enough', in the meantime Microsoft have had a similar platform meltdown of their own with WPF/UWP/WinUI , so as of 2020 'native' in Windows means literally nothing with Windows 10 a mishmash of every technology going and apps likewise.

For what it's worth I think the best strategy for labview in the near term is:

• A cross-platform back end (presumably they are already had/have this with CG?)
• A front end with bindings to multiple GUI technologies
• Python support, particularly for dynamic runtime scripting

I appreciate that the front end IDE will be tricky but moving this out to another technology (could be integrated somehow into the labview IDE) would not be the end of the world.

The cross platform backend they definitely have already. It exists since the early days of multiplatform LabVIEW whose first release was version 2.5 on Windows. It was originally fully written in C and at times a bit hackish. The motto back then was: make it work no matter what even if that goes against the neatness of the code. In defense it has to be said that what is considered neat code nowadays was totally unknown back then and in many cases even impossible to do, either because the tools simply did not exist or the resulting code would have been unable to start up on the restrained resources even high end systems could provide back then. 4MB of RAM in a PC was considered a reasonable amount and 8MB was high end and costing a fortune. Customers back then were regularly complaining about not being able to do create applications that would do some "simple" data acquisition such as a continuous streaming of multiple channels at 10kS/s and graphing it on screen with a PC with a "whooping" 4MB of memory.

The bindings to multiple GUI technologies also exists. The Windows version uses Win32 window management APIs, and GDI functions to draw the content of any front panel, Mac used the MacOS classic window management APIs and Quickdraw and later the NSWindows APIs and Quartz, while the Linux version uses for everything the XWindows API. These are quite different in many ways and that is one of the reason why it is not always possible to support every platform specific feature. The window and drawing manager provide a common API to all the rest of LabVIEW and higher level components are not supposed to ever access platform APIs directly. But moving to WPF or similar on Windows would not solve anything, but only make the whole even more complicated and unportable.

The LabVIEW front end is built on these manager layers. This means that LabVIEW does basically use the platform windows only as container and everything inside them is drawn by LabVIEW itself. That does have some implications since every control has to be done by LabVIEW itself but on the other hand trying to do a hybrid architecture would be a complete nightmare to manage. It would also mean that there is absolutely no way to control the look and feel of such controls across platforms. You have that already to some extend since LabVIEW does use the text drawing APIs of each individual platform and scales the control size to the font attributes of the text as drawn on that platform, resulting in changed sizes of the control frames if you move a front panel from one computer to another. If LabVIEW would also rely on the whole numeric and text control as implemented by the platform those front panels would look even more wildly different between computers.

And no, front end moved into the IDE is not a solution either. Each front panel that you show in a build application is also a front end part so needs to be present as core runtime functionality and not just an IDE bolted on feature. 

[ShaunR]

7 hours ago, LeeH said:

A front end with bindings to multiple GUI technologies

You can kind of do that with VI Server, Wireshark and a lot of determination  It's not very secure and not at all documented though. Now. If we could connect to VI server with wss and ... <thoughts for another time>

[ensegre]

On 12/18/2020 at 5:02 PM, Rolf Kalbermatter said:

That does have some implications since every control has to be done by LabVIEW itself but on the other hand trying to do a hybrid architecture would be a complete nightmare to manage.

Just spitballing without knowledge, but via anything modern like Qt perhaps?

[Rolf Kalbermatter]

On 12/19/2020 at 6:54 PM, ensegre said:

Just spitballing without knowledge, but via anything modern like Qt perhaps?

QT from a pure technological view might be a good choice. From a licensing point of view it might be quite a challenge however.

Qt | Pricing, Packaging and Licensing

That all said, they do use a QT library in the LabVIEW distribution somehow. Not sure for which tool however, but definitely not the core LabVIEW runtime. If it is for an isolated support tool, it is quite manageable with a single user license. For the core LabVIEW runtime, many of the LabVIEW developers would need a development license.

And some of the QT paradigms aren't exactly the way a LabVIEW GUI works. Aspect ratio accurate rendering would most likely be even further from what it is now with even bigger differing results when loading a VI frontpanel on different platforms.

Edited December 21, 2020 by Rolf Kalbermatter