LabVIEW on Apple Silicon M1 and beyond

[joerg.hampel]

Are there any new findings regarding performance, compatibility, stability... with the latest version of Parallels? Especially when running Windows 10 for ARM, not 11?

[funcooker]

No matter how hard I try, I just cannot get this to work on Windows 11 ARM on Macbook M1 Air. I have done all the updates on both MacOS and Windows 11, and tried to install both the 2020, 2023 32 and 64 bit versions of LabVIEW and every time I break Parallels (tried both version 17 and the new version 18).  Once LabVIEW is installed (fast startup checked or unchecked) Parallels just won’t boot anymore. 

Windows will say the following during the install process:

"LabVIEW: (Hex 0x464) VI is not loadable.
In a built application, this error might occur because the Vl being loaded was last
compiled for a different O5 or with CPU features, such as 55E, that this target does not
support. In this case you must rebuild the application for the target O5 and make sure 55E
compiler settings in the build specifications match the target platform. This error also
might occur if the Vl is a polymorphic VI, which cannot be loaded in the LabVIEW Run-
Time Engine. You must load an instance of the polymorphic Vl instead of the polymorphic
VI itself.
An error occurred loading VI 'VIPM - Check is Windows Task Running by Name.vi".
LabVIEW load error code 57: This Vl was compiled on a platform with CPU features not
available on this host (SE/SSE2). Rebuild the application with SE disabled to support"

and then once it has installed, upon restart it will crash and then will never boot again. It simply says INACCESSIBLE_BOOT_DEVICE during startup. 

If anyone can help me it would be much appreciated. I am meant to teach this development system to students soon (many of them who will be using M1 Mac laptops and I am sure will be quite angry at the lack of support for LabVIEW and their MyDAQs). 

Thanks 

[_Chris]

Hi Funcooker

I was able to install LV 2022Q3 in Parallels 18 (Business) with W11 on a mac mini M1 running Mojave.

*BUT* as soon as I install DAQ drivers my VM crashes (W11 blue screen at start up) and I have to revert to a previous snapshot.

I've had similar behaviours (DAQ crashes the VM) with Parallels 17, W10 and LV 2021SP1

You can contact me directly if you want to check Parallels settings step by step.

Best

Chris

[funcooker]

Hi Chris, 

thanks for getting back to me so quickly. I will try once more with LV2023Q3 (64 bit?). If it doesn’t work I will contact you. 

So is it safe to say that students who have the NI MyDAQ will not be able to use them in any way on Apple Mac M1 machines? As I know that a lot of students use mac and have historically dual booted Windows and used the x64 drivers. This is going to upset a large number of our cohort if DAQmx drivers aren’t provided.

Thanks and best wishes

Sam

[_Chris]

It is safe to say DAQ driver won't work on M1/2, at least for now.

But myDAQ is USB based and could run in user space. I don't know about NI plans, but in theory it could run on LabVIEW OSX M1/2 once it is released. Note that everything is very easy in theory....

I know it is possible because we have Quanser QUBE2 connected via USB running on LV 2021 (emulated) on M1.

Best

Christophe

[santo_13]

From what I read, it has been really challenging to support ARM architecture for NI as historically NI has supported only x86 architecture and all the software and drivers were developed for x86 architecture and not ARM.

[rolfk]

That is factually wrong. At least LabVIEW was in the past running on CPU architectures like Sparc, PARisc, PowerPC, and ARM. It is true that NI always had a hard time to figure out how to support non Windows x86/64 systems for their hardware drivers.

But at least for ARM they to have the NI Linux for ARM targets which even support DAQmx since quite some time. Of course this is ARM32 which is not the same as the ARM64 on the Mac models. Add to that that the ARM architecture on the Mac is not fully open as Apple has some trouble to openly document the entire architecture.

The main problem is also not the actual CPU architecture used on a computer, that is for the most part transparently handled by the C compiler toolchain to compile the (kernel) drivers. The real problem is the OS and how kernel drivers need to be integrated in each OS. While Microsoft traditionally put a lot of effort into trying to keep everything backwards compatible, Apple was usually a lot easier about simply declaring something obsolete and requiring everyone to jump on the other leg if they felt like it.

[santo_13]

@Rolfk, thanks for the correction and explanation!

[Kernelmeister]

Hi,

did you ever manager to get past the unaccessible_boot_device by disabling "disable windows fast startup" through cmd in recovery mode?

[CarstenPXI]

I've never tried that, but recently got my community editing running without that.