LabVIEW (LVA) license advice

[jcstoke]

I need advice on SCADA/DAQ options for my company.  We are a small (aerospace) startup with app 30 engineers at present and plans to hire many more in 2022+.  My background, I am an EE with Math/CS graduate school education, 30 years of industry experience working for various companies both as an FTE and as a consultant/contractor (NI Alliance partner).  I have been in a management role for the last several years which I thought would lead to early retirement.  As it turns out I'm not well suited to being put out to pasture -not just yet anyway.  I had no intention of ever being an FTE again, but never say never is probably a good mantra. I am enjoying the energy, excitement and opportunity to help define and implement our data acquisition and control systems.   To that end, I am seeking advice and opinions on using NI SW and HW, specifically LabVIEW licensing e.g. packages (full, professional), subscription vs perpetual, PXI vs cRIO vs cDAQ.  In the past as an Alliance Partner I had access to most/all of NI's software. We used LabVIEW/RT/FPGA & TestStand  extensively in designing and building rack based functional/end of line testers, embedded controllers and laboratory SCADA systems.  In the past few years NI has changed considerably.  While I don't necessarily agree with all of the changes -I do understand the motivation.   Case in point I never used NGX for a commercial project, we stuck with traditional LV (all the way from 3.x to 2019).  My experience with NXG is limited but the little I saw I really liked.  I'm saddened to see it die.  I've always been a little leery of having a single source solution e.g. LabVIEW but the advantages seemed to out weight my concerns. I've read many posts (on LAVA, NI, Reedit, etc.) with interest regarding NIs (and LVs) future.  I agree with most of them.  But back to my question,

Currently we are using,

1. An inhouse developed SCADA application written in LV 2020
2. various (cDAQ) chassis and modules (from NI and UEI)
3. LabVIEW is installed and running on a server connected to the HW item 2 above via a fiber based high speed dedicated link appx 200m away
4. writing data to flat files with 3rd party data analysis/visualization packages

My current thoughts are to ( I have an aggressive schedule)

1. refactor/cleanup existing LV code (using LV2021) 
2. buy LabVIEW 2021 license subscription(s)
3. use the VLA/VLM (start with 5 seats and add more as needed)
4. use PXI as the primary HW (as opposed to cRIO/cDAQ)
5. use external controller (PC) as opposed to an embedded one (contained in the PXI chassis)
6. build the next DAQ system using a 19" EIA rack with PXI chassis and local controller (PC), use cRIO where needed
7. build WEB based HMI for remote monitoring and control
8. use TDMS and/or SQL database

BTW, there is a clear negative perception of NI/LV here.  Most of the engineers are young (30ish) and pretty convinced Python is the sh*t.  I'm not opposed to using text based languages (where appropriate).  I still think LV has some advantages, e.g. development time, in this environment/use case.   Given my recent experiences (e.g. horrible support, not returning calls/emails, access problems) and perhaps most damning of all, I've lost faith/don't trust them.  If I didn't have a 30 year relationship with them, I'd tell them to f-off and vote with my feet.  

[Jim Kring]

hey @jcstoke

I would stick with LV2020 SP1 at this point. There has been a LOT of grief around the wire auto routing behavior in LV2021.

Note: an active LabVIEW subscription will allow you to install older versions of LabVIEW (not just the most current), if you like. That's good, IMO, since it encourages people to both play with the new releases (and provide feedback earlier) and also stick with older and more stable releases when needed for production.

To your questions about PXI vs cRIO/cDAQ it really depends on a lot of different factors

Also, Python *really is* the s#!t. I probably spend as much time in Python as I do LabVIEW these days. They can play nice together, for sure.

[ShaunR]

You are pretty much locked into NI at this point so I would be looking for ways to mitigate and diversify without throwing everything out and starting again. That means making future choices that replace piecemeal. This is a lot easier with software than it is with hardware.

1. Keep LabVIEW 2020. You probably have more than 5 years or so before it is completely obsoleted and you will not lose access to it with a perpetual licence. Make sure you keep the full installer and not the download installer! I still use LV2009 (through preference) and only compile for later versions as customers require it. LV2020 brings TLS and this is a must-have, nowadays so if I didn't have my own TLS solution, I would have upgraded to it from 2009.
2. I resist the subscription model in principle. So make of that what you wish.
3. See 2.
4. Keep what you have. It works, right? As you add more or start to replace stuff, look for alternatives.
5. Depends if real-time is required. By all means have an external PC with databases and servers etc but if you need a real-time controller this will be difficult. An external PC is not generally a replacement of local controllers, it is usually a configuration and data collection station.
6. Only you can answer that according to your specific current and future requirements.
7. Yes. I moved to this a couple of years ago and never looked back. This is maybe where you would use the external PC but it can easily be provisioned and maintained by IT. You will also have a greater pool of resources to develop with as Web Devs are what you need, and they are plentiful.
8. TDMS is only really useful if you are doing high-speed datalogging of large data-sets. Given 7. SQL over the network and SQlite locally should be the first choice.

6 hours ago, Jim Kring said:

Also, Python *really is* the s#!t.

You only need a "garbage collector" to clean up garbage  It's an interpreted scripting language, with the heavy lifting done by C/C++, masquerading as a general programming language. It's also a lovey of the Linux world so expect ABI breaks often like with v2-v3.

Edited December 30, 2021 by ShaunR

[Jim Kring]

2 hours ago, ShaunR said:

You only need a "garbage collector" to clean up garbage  It's an interpreted scripting language, with the heavy lifting done by C/C++, masquerading as a general programming language. It's also a lovey of the Linux world so expect ABI breaks often like with v2-v3.

In C/C++ *the programmer* is the garbage collector (at edit time) -- I'd rather have someone else take the trash to the dump for me 🤣

[Michael Aivaliotis]

I would use a PXI chassis with an NI embedded controller. However, you need to decide if you get a Linux controller to run LabVIEW Real-Time or Windows. It depends on what you want to do. It sounds like you have some power in the decision-making, so I would look at what the final outcome should be and work your way back from that. If existing components can be used, fine, but don't be married to them. Sometimes creating the glue that sticks old stuff together is a headache. Question what the issues are with the current system and see how things can be improved or automated to save time and operator errors. At the end of the day, if you are responsible for the outcome then you want to put your best foot forward. Let someone else higher up slash your budget if they have to but do a proper design. If everything works, nobody will question your decision, but if it fails, then you will have to justify why you cut corners and didn't go for the better solution.

As far as licensing, get what is most cost-effective for your team, assuming more than one person will be developing with LabVIEW. You don't need a full LabVIEW license if you are running an executable or doing Real-Time. But of course you probably know that already.

I've worked in Aerospace, Semiconductor and a multitude of other industries about the same amount of time as you.

[jcstoke]

I really appreciate your (JK, SR, MA, et.al.)  responses and expert advice .  I am enjoying being back in an engineering/coder role -specifically looking at ZMQ, Python/LV, GIT, etc.  In another thread and when time permits, I hope to write about my introduction to LV (way back in the 90's) and some of the jobs/contracts/projects I have been involved with.  It has been an interesting journey to say the least.  Again, thanks to all of you for your help.