10-16-2023 06:07 AM - edited 10-16-2023 06:09 AM
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.
10-16-2023 06:46 AM
@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).
10-17-2023 01:14 PM
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)
10-18-2023 04:39 PM
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.
01-12-2024 10:04 PM - edited 01-12-2024 10:05 PM
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 🙂