LabVIEW subscription model for 2022

[BertMcMahan]

---

@pawhan11 wrote:

Subscription is ok but prices are overkill,  paying more than 2k eur for 1 proffesional seat to do desktop programming makes no sense when one can buy Visual Studio , Rider or many others for 500 eur max. Convincing any management to invest in this will be almost impossible.

---

Don't forget though, you can get LV Base alone for $528 a year (466 Euro). It's $2k for the Test Bundle thing that includes Flexlogger, DIADem, and some other stuff I've literally never used before. LV Full is $1664 a year (1400 Euro, according to Google), and Pro is $2700 a year (2400 Euro). Test Bundle Thing Pro (which includes LV Pro) is $4k a year.

I don't like the subscription model either, but their marketing approach of trying to bundle a bunch of software into one (and making it look like you HAVE to buy the bundle) is also a big mistake. Their bundles and their incredibly complicated menu system for trying to just buy what you want are very confusing... I suspect intentionally so. They want you to buy the big ol' bundle.

[JimB.]

---

@BertMcMahan wrote:

---

@pawhan11 wrote:

Subscription is ok but prices are overkill,  paying more than 2k eur for 1 proffesional seat to do desktop programming makes no sense when one can buy Visual Studio , Rider or many others for 500 eur max. Convincing any management to invest in this will be almost impossible.

---

Don't forget though, you can get LV Base alone for $528 a year (466 Euro). It's $2k for the Test Bundle thing that includes Flexlogger, DIADem, and some other stuff I've literally never used before. LV Full is $1664 a year (1400 Euro, according to Google), and Pro is $2700 a year (2400 Euro). Test Bundle Thing Pro (which includes LV Pro) is $4k a year.

Don't forget the Application Builder module at $824 a year if you aren't getting Professional.

I wonder... How many of you are running VIs in the development environment? Just using LabVIEW as a standalone tool on some lab machine? That doesn't work for me, but maybe I'm underestimating the portion of the user base that it does.

If we are going to talk about those lower tiers, then that might be what stands out most compared to VS, Jetbrains, or just about any other paid, "development environment." I can't think of another IDE that can't compile an executable.

[billko]

I think devs that use TestStand will use LV in dev mode.

[crossrulz]

---

@billko wrote:

I think devs that use TestStand will use LV in dev mode.

---

Many do.  I build my LabVIEW code into PPLs and have the TestStand call the VIs in PPLs.  So I just need the LabVIEW Run Time Engine.

As far as other dev tools that do not build into an executable: Python.

[santo_13]

A considerable advantage in LV over other Dev Tools is the availability of non-licensed industry oriented libraries. In most cases, for other languages, you do get some open-source library but you've to check the license etc., before including it in your commercial product.

Note: not third-party toolkit, but anything NI, we don't have to fret about license terms of distribution, either they work or they don't and ask for deployment license.

[alexderjuengere]

---

@JimB. wrote:

---

I wonder... How many of you are running VIs in the development environment?

---

Often, I can't run the .vi in the IDE (due to lack of hardware or other ressources like RAM, storage) and have to compile an .exe for testing.

[alexderjuengere]

---

@crossrulz wrote:

As far as other dev tools that do not build into an executable: Python.

---

kudos for pointing this out.

[Jay14159265]

---

@alexderjuengere wrote:

---

@crossrulz wrote:

As far as other dev tools that do not build into an executable: Python.

---

kudos for pointing this out.

---

I think this is an interesting point for some use cases. 

If your code never leaves the company, you might want to make an executable to make the code more portable because you don't want a dev system on every computer. for many reasons but notably because running LabVIEW on every company computer is expensive. 

If your code does leave the company and has some IP in it you might want to compile so people cant see it.

What if IP is not an issue? You can run a Python dev system on any computer for free and you can package, distribute, and install python apps on any computer. So is the ability to generate an executable only of interest if you have some IP you want to protect (or if you just like having an executable)? 

I would guess there are more LabVIEW applications that are internal and never get distributed than ones that are distributed / sold. 

[rolfk]

---

@Jay14159265 wrote:

---

What if IP is not an issue? You can run a Python dev system on any computer for free and you can package, distribute, and install python apps on any computer. So is the ability to generate an executable only of interest if you have some IP you want to protect (or if you just like having an executable)? 

Well, installing an executable on a test machine is considerably easier than getting LabVIEW installed properly, all the drivers setup right, the LabVIEW source code installed in the right location, OpenG Toolkit, JDP Science Libraries, JKI Libraries, NI Labs Libraries this and that, and a myriad of other Toolkits and libraries installed on a machine. That in itself is a main selling point for creating executables, not to speak about an untrained operator messing up your program because he thought changing that front panel just this little bit would be making the program run faster.

Sure the original traditional LabVIEW user some 30 years ago was a PHD lab researcher who was setting up his own program and making changes on the fly as the experiment was developed. He always worked in the LabVIEW IDE, but that is not the default operation mode for many end users of LabVIEW applications anymore.

I would guess there are more LabVIEW applications that are internal and never get distributed than ones that are distributed / sold. 

---

Can't speak for the rest but we develop test systems that are working on manufacturing floors and the clients would be pissed if they had to deal with LabVIEW details to operate our machines. Quite often the client does get access to the project source code of the LabVIEW program, but for most it means it is archived somewhere in a safe location and never looked at again.

[RTSLVU]

---

@rolfk wrote:

---

@Jay14159265 wrote:

---

What if IP is not an issue? You can run a Python dev system on any computer for free and you can package, distribute, and install python apps on any computer. So is the ability to generate an executable only of interest if you have some IP you want to protect (or if you just like having an executable)? 

Well, installing an executable on a test machine is considerably easier as getting LabVIEW installed properly, all the drivers setup right, the LabVIEW source code installed in the right location, OpenG Toolkit, JDP Science Libraries, JKI Libraries, NI Labs Libraries this and that, and a myriad of other Toolkits and libraries installed on a machine. That in itself is a main selling point for creating executables, not to speak about an untrained operator messing up your program because he though changing that front panel just this little bit would be making the program run faster.

I would guess there are more LabVIEW applications that are internal and never get distributed than ones that are distributed / sold. 

---

Can't speak for the rest but we develop test systems that are working on manufacturing floors and the clients would be pissed if they had to deal with LabVIEW details to operate our machines.

---

I deploy my LabVEW executables on 10 ATE systems and countless other tests going on in the lab.

Can you imagine having to buy a LabVIEW license for every single computer that is running a test?