[New Feature] macOS Big Sur Support

[sth]

That is certainly an error during save!  As a quick thought, it seems to not know what VI it is saving and has an empty pointer to a VI.  How it loses track of that reference is a problem for the developers.

One weird thing is that the file lists your OS as 10.16???  Big Sur is listed usually as 11.X.  Not sure how LV determines the OS version but something seems off.  Running the sw_vers command from the terminal should give the OS version.

You installed the FDS (Full Development System), is there an option to install the PDS (Professional Development System) which may behave differently?

-Scott

[PHacke]

To your question -

>One weird thing is that the file lists your OS as 10.16???  

~ % sw_vers

ProductName: macOS

ProductVersion: 11.4

BuildVersion: 20F71

and (from about this mac):

>is there an option to install the PDS 

Here is the reality via a screenshot from menu item About LabVIEW

I hope this is helpful to someone.

[PHacke]

Quite often when I double-click to open a vi from a state when LabVIEW is not running, I get an error that looks like this.

After getting the LabVIEW application running, the double click on the vi from the Finder seems to work.

[Christina_R]

It's likely that all the symptoms that you're seeing are from the same root issue.

There's a bug in Rosetta 2 that's affecting LabVIEW, causing intermittent issues with reading and writing files (including the files that LabVIEW uses for its own operation, such as resource and menu files).

LabVIEW R&D has not been able to find a workaround for this issue.

For now, I want to reiterate that LabVIEW 2021 is not supported on M1 Macs.

I can't promise a timeline, but we hope to add support for M1 in a future version of LabVIEW.

[sth]

I think that is a known issue with the beta on an M1 (Apple Silicon) CPU.  See Christina's reply on the 4th comment in this thread.

[sth]

This is a Big Sur weirdness or change in behavior.  I am not sure it can be called a "bug".  The same situation happens on Catalina and I don't have a resolution for it there either.

The File utility "Get Volume Info" is very very different now that Apple has split the OS and user space into multiple "volumes".  This is great for security and keeps malware at bay by having an immutable system volume and standard applications.

However, I had a utility that would look for calibration files in a "Shared Directory".  This was in <User Volume>/Users/Shared on the Mac.  I it would call a system utility under windows to get the shared directory (C:/Library or something like that CSIDL_COMMON_DOCUMENTS) and would just use /usr/local/shared for linux.  The <User Volume> would be determined by looking for the Volume info for the Users "Default Directory".  Now the default path is still "/Applications/National Instruments/LabVIEW 2021 64-bit" but the Volume is "/Applications" rather than "/".

I am not sure what a good resolution of this is...  My guess is that the NI response will be "Just deal with it, Scott", 🙂  But having the logical root Volume returned as "/" for some path would be nice.

[PHacke]

>For now, I want to reiterate that LabVIEW 2021 is not supported on M1 Macs.

>I can't promise a timeline, but we hope to add support for M1 in a future version of LabVIEW.

I pray for the R&D team's success.

On the other hand, please be aware that LabVIEW is not well supported (as far as I am concerned) with Intel-based laptops (macos or windows). When running with an external monitor and with an active, continuously running LabVIEW vi, I see overheating and then the CPU slowing down to a crawl. See attached video for my workaround. In fairness, it isn't only LabVIEW.  Microsoft Teams is even more problematic.

So, you can see the pull and attraction from the M1 chip, despite the save/open issues that pop up now and then (that seem to have workarounds).

[sth]

---

@PHacke wrote:

I pray for the R&D team's success.

On the other hand, please be aware that LabVIEW is not well supported (as far as I am concerned) with Intel-based laptops (macos or windows).

---

LV like any language can overload a CPU or a GPU (or both!).  I am not sure this is a question of "well supported" and you have an application that is overwhelming the thermal management of your machine.  The M1 chip is not going to solve this since the lower thermal demand of the chip will just mean that folks will write more demanding code AND the engineers will reduce weight and size of the laptop as they remove unnecessary thermal management structures from the system.  If you need that kind of performance you need to move to an iMac pro.

The LV code generation is reasonably efficient though large.  If you system is overloading due to VM faults that might be a reason for slowdowns and thermal issues.   Or your fans are clogged with dust on the laptop.  Laptop fans do wear out.

[PHacke]

sth, Thank you for your comments. Of course you are right in almost all respects, but I don't think anything you wrote negates my observables. Bottom line is, unless NI disables LabVIEW from working on the M1 (and I sincerely hope they do not), based on what I see, I will continue to favor purchases of M1 Macs for my applications involving running long term calculation-intensive programs. Of course I still buy Wintel boxes for applications requiring NI Max and the like.

[sth]

---

@PHacke wrote:

based on what I see, I will continue to favor purchases of M1 Macs for my applications involving running long term calculation-intensive programs. Of course I still buy Wintel boxes for applications requiring NI Max and the like.

---

Despite being a LV advocate for a few years (> 30) LV does not generate the most efficient code for calculation intensive programs.  In addition LV applications (including built applications and runtime) have a very very large footprint that necessitates a lot of swapping for the VM leading to huge inefficiencies.

I would suggest calling out of LV into a highly optimized library for the calculation intensive portion of your application.  I am not sure if an application running using Rosetta 2 can call a library and run in native optimized ARM code.  But that may be something to look into.  Even running an optimized M1 application and using IPC calls to communicate to your LV code may be a big improvement over the kludgetech fan setup you seem to be running!

Note that Rosetta 2, takes the binary generated and translates it into ARM code that is then run natively.  It is not an interpreter but a recompiler.   I am not sure how this affects benchmarking in the development environment vs. built applications but you may get a performance boost by building an application.

just some random thoughts on a Tuesday morning.