LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

LabVIEW subscription model for 2022

Solved!
Go to solution

@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.

Message 11 of 748
(5,311 Views)

@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.

Message 12 of 748
(5,248 Views)

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

Bill
CLD
(Mid-Level minion.)
My support system ensures that I don't look totally incompetent.
Proud to say that I've progressed beyond knowing just enough to be dangerous. I now know enough to know that I have no clue about anything at all.
Humble author of the CLAD Nugget.
Message 13 of 748
(5,228 Views)

@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.


GCentral
There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines
"Not that we are sufficient in ourselves to claim anything as coming from us, but our sufficiency is from God" - 2 Corinthians 3:5
Message 14 of 748
(5,187 Views)

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.

Santhosh
Soliton Technologies

New to the forum? Please read community guidelines and how to ask smart questions

Only two ways to appreciate someone who spent their free time to reply/answer your question - give them Kudos or mark their reply as the answer/solution.

Finding it hard to source NI hardware? Try NI Trading Post
Message 15 of 748
(5,177 Views)

@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.

 

 

Message 16 of 748
(5,133 Views)

@crossrulz wrote:

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


kudos for pointing this out.

Message 17 of 748
(5,132 Views)

@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. 

______________________________________________________________
Have a pleasant day and be sure to learn Python for success and prosperity.
Message 18 of 748
(5,058 Views)

@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.

Rolf Kalbermatter
My Blog
Message 19 of 748
(5,050 Views)

@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?

========================
=== Engineer Ambiguously ===
========================
Message 20 of 748
(5,044 Views)