Make a case for LabVIEW native ARM64 build on Windows on ARM

[ycuisc]

Microsoft had a sale on Black Friday, so I got my first ARM laptop Surface Laptop. The laptop run beautifully on ARM. This made me trying to make a case to ask NI to have a native ARM build 

The background ground:

1. Python is eating a lot of hobbyist market from LabVIEW

2. The rise of AI vibe coding definitely does not help LabVIEW in anyway. 

3. On NI's roadmap, code generation from Nigel is still a year away. 

4. Hobbyist buying a lot Raspberry Pi for home projects. 

5. University use Raspberry Pi to educate their students. 

6. Existing ARM capable LabVIEW is headless, has no GUI. Student won't have the time or lac of the capability to write a GUI utilizing Web Services. (Although I would say that would be real nice.)

7. Hobbyist are cost sensitive. Having a Windows capable X86 machine is expensive, compared to Raspberry Pi or BeagleBone solutions. Thus, this prevents many hobbyist projects from happening on LabVIEW. 

8. If students or hobbyists don't use LabVIEW at home, they likely would stay away from LabVIEW at work. In a few to ten years, LabVIEW will lose even more market share. 

9. Not being able to run LabVIEW on majority of ARM devices will force many engineers to pick text-based language to begin their project. They have no incentive to redo it in LabVIEW on x86 Windows machine. No one want to develop things twice. 

So, now the benefit and other thinking:

1. Allowing ARM64 native build will open opportunity to hobbyist and student. 

2. ARM64 would allow LabVIEW to run on Raspberry Pi on Windows on ARM. 

3. ARM native build can start with minimum LabVIEW, device drivers won't be necessary. Is it not like the Hobbyist will pay over-priced NI DAQ devices anyway.

4. Allow arm64 dll to be called via LabVIEW. (One benefit is that Digilent's devices, a NI subsidiary, can be used on LabVIEW. 

5. ARM64 laptop will sleeps better, they less likely to BSOD upon wake up. (Thank NI for making our whole departments' laptop BSOD every morning by their faulty PCIe driver. It would be a benefit to all people, if the native ARM build does NOT support any PXI at all.

6. NI should make Raspberry Pi/BeagleBone officially support for hobbyist market. This market does not make any money for NI likely, but losing this market will lead to eventual demise of LabVIEW in long term, given the current rise of Raspberry Pi/Beagle Bone, etc. So many companies are building their industrial equipment on Raspberry Pi and such. 

7. Maybe also fix the LabVIEW on 64-bit Raspberry Pi OS. Just need to update arm64 to armhf in the package description. 

[crossrulz]

Based on news in the First Robotics working on a new controller that is ARM based and NI plans to support it, I would say this is already in the works.

[NORgated]

Running on Smartphone, at least Android, should be coupled with this. Enabling hobbyist/makers to easily make smart phone apps coupled hardware over phones USB would be something totally new and could further lower entry costs for hobbyists (they already have a phone). Making LabVIEW apps, seamlessly portable to Rpi further eases the path to embedded devs.  This also gives NI easier portability in their own future hardware offerings.  

[rolfk]

I'm not sure I would get my hopes up to much. The First Robotics platform called SystemCore may be based on an ARM controller but so is the roboRIO, myRIO, the cRIO-906x and sbRIO-9651 and several other sbRIO's. And the Raspberry Pi and the Beaglebone Black. Each of these can be already made to run a LabVIEW executable in so called headless mode, meaning they do NOT have a normal display that can be used by the LabVIEW application to show user interfaces. The new SystemCore platform is very similar as it seems to be based on the Raspberry Pi Compute Module 5 ARM controller but that is a minor technical detail. The display on the SystemCore hardware is a small character based LCD device that can NOT display UIs such as a LabVIEW front panel. As such it is simply another variant of the already existing ARM based LabVIEW remote deployed devices.

That's a far cry from a LabVIEW IDE that can be installed and run on an ARM based Windows or Google Chrome machine.

You can already develop and run runtime applications for any Raspberry Pi except the Picos by using the Community Edition or the Hobbyist Toolkit. But yes it could use some love, its installation and use is not exactly straight forward.

As to running the LabVIEW IDE on smartphones (or any touchscreen for that matter): I'm not convinced anyone would be using that! LabVIEW IDE operations on a touch screen are simply awkward  and unpractical to do. It would require a complete overhaul of the LabVIEW UIX and that would alienate 99% of the existing user base. As such it would be more likely another nail in the coffin, rather than an opportunity for NI to attract new users.

[NORgated]

Hi Rolf,

Re: smartphone, I was referring to deployments, not necessarily to IDE on smartphone.  However, I do think that making the IDE and deployments more universal, including compatible on smartphone would be a huge advantage and massively expand user base.  Programming is rapidly becoming NLP and with the right architecture and effort that LabVIEW, could also evolve to take advantage of this new paradigm - e.g. program in Labview while you are jogging - this is where other languages are going/at in the AI paradigm. 

I can also see pathways for even touchscreen LabVIEW dev that makes sense, enhances DX with minimal DX workflow changes - touch two wire connectors and dataflow wire auto connects/routes - could work well with Touchscreens.  While LabVIEW has some current disadvantages to text programming in the existing AI paradigm there is also tremendous unique code security advantage LabVIEW intrinsically has in the AI paradigm that text based programming languages simply can't have - the current difficulty AI has with LabVIEW programming can be a huge advantage to make it much more difficult for AI to fully reverse engineer/fully make sense of LabVIEW application source code in certain code architecture scenarios.