Final release for macOS support for NI Software

[apg_air]

Thanks for the answers, I thought that would be the case.

Just trying to get my head around the subscription model. I work as a contractor producing Test Systems and I was trying to work out whether it was better to try to talk the companies I work for to pay for the subscription while I am there, or for me to pay and just supply executables, or both!!

If I use my own copy of LabVIEW and I leave a company just with executables then I suspect they will moan that they will have no way of supporting the code themselves. Also, if I then got a contract at another company which doesn't wont let me use LabVIEW then I have paid for a subscription I might not use for a while.

At the company I am currently working at I did talk them into paying for a copy of LabVIEW Pro 2021, it did take a lot of work/discussion for this to happen. I was asked by numerous people why don't I use C and Python but I stuck to my guns. At least when I leave this contract they will still have a working copy of LabVIEW to perform any changes they require.

[crossrulz]

---

@apg_air wrote:

I work as a contractor producing Test Systems and I was trying to work out whether it was better to try to talk the companies I work for to pay for the subscription while I am there, or for me to pay and just supply executables, or both!!

---

Look into the NI Alliance Partnership.  As part of it, you can get nearly all NI software (Software Reference Library) really cheap (relatively).

[EricR]

@apg_air 

1) For the company you work for, if they want the ability to continue accessing the source code, you have a few options.  They can use the community edition (free) or you can sell them a copy of the LabVIEW Debug/Deploy.  That license is perpetual and they can use it to EDIT the source code you leave them with, for the purposes of debugging and fixing issues, and even rebuilding the executable if they need to. 

2) We are interested in talking to you about the workflows you need to support in your scenarios and making sure we have options in place that meet your needs.  Please reach out to me directly if you want to talk to me further.   (eric.reffett@ni.com)

[EricR]

NI supports ARM-based devices running linux for its embedded targets for deployment scenarios.  NI has no current plans to support Arm-based configurations for development scenarios.

[HResearchGroup]

This is slightly off topic, but could be of interest to those looking to interface with equipment/hardware from macOS.  There are a couple current frameworks/packages that allow you to write applications to control hardware from a mac.  pyVISA (and pyVISApy) is a good python package that is really easy to setup and use (https://pypi.org/project/PyVISA/).  SwiftVISASwift is a newer package that is modeled after pyVISApy and is similarly easy to use with the benefit of having access to all of the macOS APIs, so you can write native applications (https://github.com/SwiftVISA/SwiftVISASwift).  

  Both of these packages are implementations of the VISA communication protocol and work well with a lot of equipment.  pyVISA provides a broader interface support, but SwiftVISA lets you access native APIs.

I know these aren't a replacement for LabVIEW, but they do allow you to keep using a macOS environment.  

Disclaimer: My research group developed SwiftVISASwift.  It works really well over ethernet and we have preliminary implementations of a libUSB wrapper that work.  This summer we will likely implement our own version of libUSB to get rid of that dependency and then we will fold in the USB implementation into SwiftVISASwift as a 0.3 release.  I'm also a big fan of Swift's async/await implementation that makes asynchronous programming pretty straight forward.

If you are interested in seeing some example SwiftVISASwift applications, you can find them on my research group's github site: https://github.com/HildrethResearchGroup/.  Anything that controls hardware is using either SwiftVISA (which runs on the old NI VISA framework) or our newer SwiftVISASwift (which is our own implementation of the VISA communication protocol).

I also wrote a paper introducing SwiftVISASwift that has a good beginner's application: https://joss.theoj.org/papers/10.21105/joss.04752

Hopefully this helps someone stay on macOS 🙂

[rmp]

Yikes, I wonder if NI would consider selling off the Mac version to a 3rd party... kinda like Google sold Sketchup to Trimble. Too many proprietary information issues? And, if feasible, who would be a good candidate to take it over?

[rolfk]

The Mac version isn't some magical separate code base, except maybe a few Objective-C source files to interface to a few native MacOS Cocoa APIs that aren't available as C library interface (but not even that is strictly necessary, you can interface to the Cocoa API from pure C code too, it's just a f...ing pain to do so).

As such open-sourcing or selling off the Mac version of LabVIEW would be more or less giving out the Linux and Windows version too (and the LabVIEW realtime and LabVIEW FPGA for a large part too). Even if they would not include the according make files for these other platforms, about 99% of the source code for them is in the exactly same files as what is needed for the Mac. A large part of the LabVIEW source code is platform independent. Underneath is a more or less thin layer of managers that provide a common interface to the underlaying OS services. And a large part of those managers are written in such a way that they contain the code for all the supported platforms in the same source file. So if you have a source file filemgr.cpp it contains actually file manager routines that interface to the according system APIs for Linux, Windows, Mac OS, VxWorks, Pharlap ETS, Solaris, HP Unix and several other OSes that NI never released a LabVIEW version for.

[rmp]

As a 68 yo engineer, I'd be happy to live with the current version and freeze OS (and app) updates on a Mac... if the current LV version actually worked. But, sadly, as I've mentioned in other posts... it doesn't. A simple graph with an enabled cursor flashes horribly when the cursor is moved. I've been stuck with LV 2011 on a purposely frozen MacOS 10.14 for many years now. I had hoped to upgrade to LV 2023 with a new MBA to solve memory issues with web browsers. I can get all of my important apps (Chrome, Office, Sketchup, Python, GIMP) except LV on a new MBA. As much as I liked and used Linux in the past, I need to stay compatible with my kids... I can't ask them to switch to Linux.

[apg_air]

I am still using the Mac version of LabVIEW 2022 on my MacBook, still appears to run fine at the moment. At work I use both the Linux and Windows versions. I wrote my own test executive plus I tend to use Ethernet/USB based instruments, so I can get away with developing and running applications on all three platforms if necessary (but I much prefer Mac).

In the future I intend to use a virtual Windows/Linux machines on my Mac just to run LabVIEW. Another option that works well is to buy a cheap Windows Dell PC from eBay just for running LabVIEW, and then use remote desktop from the Mac.

[rmp]

Great ideas, thanks. Makes me wonder if LV 2022 (and earlier versions) will still be available for purchase... and maybe offered at a much lower price since they're no longer supported. But, does LV 2022 run on the latest MacOS?

Yes, I've done the Labview on remote PC with remote desktop... it's been many years, but that might be the best option. I have a LV weather app that I developed that I leave running all day. It updates once an hour and I put it in a virtual display so it doesn't clutter my other work. And I do have a cheap windows laptop that I've setup to teach signal processing via a "bat radar" (I needed the Windows platform to use the NI MyDAQ).