LabVIEW subscription model for 2022

[beuvink]

You don’t always need to use the application builder… what you need is the runtime engine (also license free)

The runtime engine allows you to run any LabVIEW code on any machine.

A build LabVIEW application is just a .llb that is renamed .exe and windows can use this .exe to load any vi into the runtime engine.

up to LV 5 this is how it worked: you used lvrt.exe to run vi’s. But you needed to go trough the hassle of installing the runtime engine yourself… from CD’s and such…

You can still work in this way: make a project with nothing inside, build this as an application. With/without installer to your liking. You can also use the package manager these days to install the runtime engine.

Then launch the build executable once and now windows will know to run all vi’s with this exe.

If you do this you can call the exe lvrt2021.exe or so as it will only run compiled code.

lvrt is of course short for : LabVIEW Runtime

And adding the version number allows you to easily teach windows which version of the runtime engine to use.

[billko]

---

@Yndigegn wrote:

Hi

The Application Builder was introduced quite early in the LabVIEW (r)evolution story.

Attached is the release notes for version 3.1 which came out in 1994. It refers to an even earlier 3.0.1 version ( probably released in 1993 ).

The original file was in WRI format. I saved it in WPD format which opens fine in Word.

The document includes this paragraph :

"Providing Help Information

As a VI developer, it is your responsibility to document your VIs for users, including all information necessary to load and operate the VIs. The regular LabVIEW 3.1 documentation set is copyrighted material and should not be shipped with the applications you create."

Regards 

---

It's easy to say, "with LabVIEW 3.1 came the application builder", but the time between LV 1.0 and LV 3.1 is 9 years.  So for almost a decade, people were running LabVIEW "source" code, 100%.  Today, you will find LabVIEW source code often in TestStand applications.  If you subscribe to the TestStand model where you have a lot of little "helper VIs" and TestStand does all the heavy lifting, then it doesn't make sense to make an executable for each module.

I didn't originally mention this to start off a whole discussion about the history of the executable in LabVIEW, or whether or not it is still appropriate to use LabVIEW source code as the end product any more; I merely mentioned it to point out that once upon a time, there was no such thing as a LabVIEW executable.

[pawhan11]

From my experience all LV software was build into exe or packed libraries. Running from source on production will result in problems sooner or later, sometimes we did this in labs or academia when something had to work for few hours. Selling builder as additional package is bad decision IMHO

[Yndigegn]

Hi

For many years the LabVIEW Development System could be run on more computers, as proper activation using the License Manager was first introduced with LabVIEW 8. Not legal to do so of course.

The Application Builder was actually introduced with LabVIEW 2, in 1992 and for Macintosh only. Kodosky writes in the historical overview attached below :

"VIs are created and edited within the LabVIEW IDE, but customers need to deploy complete applications on other machines without an IDE, so with LabVIEW 2 we added functionality to build executable files.

4.2 Porting to Windows

Being restricted thus far to the Macintosh platform was very fortunate. It gave us the opportunity to develop and refine LabVIEW, incorporating 6 years of user experience and feedback, while our competitors ignored us.

Shortly after we released LabVIEW 2, Microsoft released Windows 3.1, which was still just a 16-bit OS but it could run on a 32-bit capable 386 processor."

Regards 

[Taggart]

---

@billko wrote:

---

@Taggart wrote:

---

@Kevin_Price wrote:

    Another thing to consider:  while every programming language is uniique to some extent, LabVIEW is more unique than most.  The graphical nature in general, the dataflow model, the near-absence of arcane syntax rules, the binary file format that leads to difficult diffs and merges, etc.  There's a fair bit of special knowledge one needs to be good in LabVIEW that doesn't really carry over to common text languages.  It's less of a head start toward learning C# than if you were coming from Python.  

-Kevin P, 

 The positive side to this statement is that if you can figure out how to do software engineering in LabVIEW, then doing it in a text-based language is trivial. It's kind of like engineering school where you learn to do everything the long way and then at the end they are like "oh here's a shortcut." LabVIEW is the long way.

---

I've found that the paradigms are so different (dataflow versus procedural) that they aren't directly translatable, and that something easily done in LabVIEW can sometimes be hopelessly (for me) difficult in a text-based language.

---

I've found a lot of the algorithms transfer easily to Python. OOP is pretty much the same. The challenge is the native parallelism of LabVIEW is harder to replicate in Python.

[HB@BNT]

It would be very convenient, if NI device driver and corresponding Python packages would support asyncio with coroutines.

Best Holger

[billko]

---

@Taggart wrote:

---

@billko wrote:

---

@Taggart wrote:

---

@Kevin_Price wrote:

    Another thing to consider:  while every programming language is uniique to some extent, LabVIEW is more unique than most.  The graphical nature in general, the dataflow model, the near-absence of arcane syntax rules, the binary file format that leads to difficult diffs and merges, etc.  There's a fair bit of special knowledge one needs to be good in LabVIEW that doesn't really carry over to common text languages.  It's less of a head start toward learning C# than if you were coming from Python.  

-Kevin P, 

 The positive side to this statement is that if you can figure out how to do software engineering in LabVIEW, then doing it in a text-based language is trivial. It's kind of like engineering school where you learn to do everything the long way and then at the end they are like "oh here's a shortcut." LabVIEW is the long way.

---

I've found that the paradigms are so different (dataflow versus procedural) that they aren't directly translatable, and that something easily done in LabVIEW can sometimes be hopelessly (for me) difficult in a text-based language.

---

I've found a lot of the algorithms transfer easily to Python. OOP is pretty much the same. The challenge is the native parallelism of LabVIEW is harder to replicate in Python.

---

Thanks - yes that is what I was getting at.  The parallelism is what I have a hard time with.  And that's probably because I'm just a hack when it comes to text-based languages.  (Better at the Visual Studio languages.)

[Hooovahh]

---

@Yndigegn wrote:

For many years the LabVIEW Development System could be run on more computers, as proper activation using the License Manager was first introduced with LabVIEW 8. Not legal to do so of course. 

---

I had forgotten about A11A11111 being my serial for a while.  We had a site license, I just couldn't be bothered to look it up all the time.  Doing this would also help obscure the real license key, since it was on the splash screen on startup.  So any presentation I was giving would show my serial.  Even after 8.0 you could go through the manual activation process, and enter A11A11111 but use the machine code to activate it.  Then it would activate but, wouldn't show the real serial on start up.

I also use LabVIEW just as a general purpose programming language all the time.  File and folder renaming or organization, automatic picture resizing, music video organization and searching, integration with web cams and VLC, PDF report generation based on logs, automatic file copy and archiving, system monitoring and status, SQLite and other database reading and writing, and utilities for doing things in Word and Excel for report generation, just to name a few.

[dj_tony]

and how can i run lv code without an exe only with runtime? i alway build application and deploy to customers machine.

btw i renew subscription untill 2025 or 2026. after that we'll stuck to lv 2021 if nothing change. the price is more thant double than SPP that was already grown by 30% 4 years ago.

the license scheme is the same of QT. you can use sw untill you pay. 

using LV at least 10 years.

[WavePacket]

https://appleinsider.com/articles/23/10/11/labview-programming-app-abandons-the-mac-after-four-decad...

I thought higher priced subscriptions were to bring with it more resource for support and features. Beginning of the end?