LabVIEW subscription model for 2022

[daphilli]

Lets break down your arguments and sledgehammer them a bit:

1. Nobody can edit and compile? Open source teams work on code of comparable complexity every day, Linux or KiCAD for example.
2. Python? Slow! Executes 1.5x to 10x slower than C/C++. With savvy coding, LabVIEW can be as fast as C/C++ -I demonstrated this at SCU. This impacts data analysis throughput. And, this is critical during analysis of video data from high speed manufacturing robots, where analysis must be completed and decision made in the 1s-3s timespan of the move.
3. OpenTap? The website reads like autogenerated hype from a chat bot. To be fair, I'll have to look at it more but from what I've seen so far, it probably won't fit my needs. For example, it is centered around using a sequencer to execute a series of modules executing test steps. I did something like this in LabVIEW in 2007. But now, I need solutions with many operations happening concurrently for directing many machines operating in parallel and LabVIEW supports this.
4. Libraries and frameworks? There are 2088 open source LabVIEW projects on GitHub. I'm working on my own.
5. Massive abstraction? Text languages are also abstractions of machine code. The difference is that the drawn language of LabVIEW offers more degrees of expression for interpreting the code. This reduces the time required to read and understand code for debugging, maintenance and reuse. In many cases, I can help teammates debug their code, simply by staring at it for a minute or two. In contrast, the overhead for understanding legacy text code is so high that programmers often toss and replace it, resulting in bugs from loss of the knowledge gained from the previous effort.
6. Any decent programmer can code in .NET or Python? There are several problems with this argument...

1. Not with the same team. I can't train a technician or hardware engineer and expect them to quickly complete a project in .NET or Python -the learning curve is too long. This is a problem if there is not enough software work to support a programmer.
2. Not with the same productivity. I would need to pay 2-5 programmers to match my LabVIEW output.
3. Not with the same sophistication. Text code with cyclomatic complexity >10 is tough to implement and unmaintainable. In LabVIEW, some of my successful projects have 2300 cyclomatic complexity.
4. Not with the same easy utilization of hardware multicore and multithreading capabilities. The overhead of implementing this with text languages is much greater.
5. Not with the same solution throughput. In 2008, I was completing analog semiconductor tests at a rate of 1/day by leveraging meta programming and code reuse in LabVIEW. As far as I know, nobody has done this in .NET or Python.

My experience is that there are two main issues with LabVIEW

• High price.
• Editor slows down when working on big, complex projects.

So far, I have not found any replacements for LabVIEW that meet my requirements.

[Taggart]

---

@daphilli wrote:

Not with the same sophistication. Text code with cyclomatic complexity >10 is tough to implement and unmaintainable. In LabVIEW, some of my successful projects have 2300 cyclomatic complexity.

Glad I am not the one maintaining that code. 

[spms00]

Hi Eric,

I'm sending this message from France, where I work in a public research lab (using labview)

There is a strong debate at the moment to switch from labview to python for our needs (that are quite basic) as the cost of the licence-fee would be too high on an annual basis

There is a general trend in the french academy to switch from proprietary software to open source, and the subscription change will probably trigger a university-wide victory of python over labview, as young people are usually better trained in python anyway, and the added value for labview (ease of development essentially) does not compensate for its cost.

To help you understand, the university in France cannot change fundings use at the local level, so money granted f for salaries can't be used to buy stuff, whereas a private company would calculate the additional cost of quicker/longer development time vs the licence price.

I really think this has been a very bad choice from NI, because there is clearly no incentives to give undergrad students labview classes anymore, as they won't be able to get a licence during their PHD anyway: from our perspective it's much better to train them in Python or R or C++

I hope this message will find you,

Regards

Xavier

[BertMcMahan]

IMHO, LabVIEW should be free (or at least super cheap) for educational use anyway. Maybe NI gets a ton of money from this sort of thing but I can't imagine it. My university switched off LabVIEW years ago due to low usage rate, plus the high costs. Free or cheap educational use means the community grows and you have more and more developers using it professionally, which is a better long-term value for NI than trying to squeeze a few nickels out of a school while someone's there for a few years.

Look at what Autodesk did with Fusion 360 (a CAD program)- it's free for home use and educational (like the LabVIEW Community edition) and it absolutely exploded in popularity over the last few years.

[rolfk]

I’m not sure about the current pricing structure but LabVIEW for educational uses was very cheap for a very long time. It was 90% or more off from the normal price so if that would not fall under your cheap umbrella, I think the only thing that would is if it would be entirely free. Which, considering the administrative overhead, not to talk about the development effort, is a bit of an extreme request.

[1100fps]

Years ago, NI was common in university environments, NI had a wide range of student/experiment friendly interfaces.  More an more the PhDs we brought in were conversant in MatLab, and not LabVIEW. Matlab is great for analytical and research envionrments, but not so good for industrial and process controll.  

I believe that NI would be much better off strongly supporting education as a long term strategy to build a fanatic following into industry.

Not a common theme with Private Equity..  Sigh

[spms00]

I know very few things about the US academy environment.

In France, the labs usually have to pay for a research licence for labview, which is more expensive than the educational one (but more complete). I do not know the current price but it was around two thousand euros five years back if I remember correctly. It would be considered in the mid-range of prices in my lab, so would require approval by the head of the lab. It would typically be used to drive experiments.

The lab researchers also give classes to  young graduates and could give a labview oriented "how to build an experiment" course, corresponding more or less to labview's first level course. You could also have classes for PHDs (PHDs students are required to follow a few courses not directly related to their subject each year).

So the lab activity is a mix between "research" (so paying licence) and "teaching" (teaching licence)

I personnally proposed last year to give an introductory course to our phds, but I put it on hold this year because of the change of licence (no value into spending time teaching a language that's going to be replaced). Instead I  applied to a python course to refurbish my skills that may be a bit rusty 😁 and maybe we're going to do some arduino/adafruit course for small projects

[daphilli]

Replying to posts that appear to have been taken down...

NI Employee? My W2 says "A... ..."

OpenTAP? I looked into it more. Its not bad but not great. It is similar to but less sophisticated than work that I did for a certain semiconductor company in 2007 -16 years ago. OpenTAP is centered on a serial test sequencer. It's probably not a good solution for robotics systems with many operations occurring concurrently. For those systems, LabVIEW has clear advantages, which is why I stayed with LabVIEW instead of switching back to C++, which I wrote test systems in previously. Presently, I'm working on a much better development framework for myself in LabVIEW. Maybe I'll put it on GitHub when done.

[JimB.]

OpenTAP vs. LabVIEW seems like a very strange comparison to keep seeing.

It seems less feature rich, but, if anything, OpenTAP is an alternative to TestStand. It is not an IDE or a programming environment and, aside from the argument that using it would tend to push one away from coding in LabVIEW, it has very little to do with LabVIEW at all.

In theory, you could still write the actual test code in LabVIEW. Architecturally, this isn't that different from people that write a .NET GUI over the TestStand API, which quite a few do. However, there not being any LabVIEW "adapter" would make interfacing with the code more difficult. You'd likely need to write quite a number of wrappers. But I digress...

Honestly, what I find interesting about OpenTAP is that everyone that brings it up points out that it's open source as if that is the defining feature... but many of us work for companies that would not qualify for Keysight's "Community Edition" licenses for the editor and other tooling around it. (Most of which appears to be closed source.) Unless you want to start with just an engine and write your own sequence editor right from the beginning, or you're at a fairly small company, you're probably trading TestStand for PathWave.

[Ants_at_work]

Some of my few customers do transfer to Delphi (RAD Studio). It also has partly graphical IDE like Visual Studio, can compile code much smaller than Python, executes faster than Python, can use Python libs (core numpy is written in C++ anyway), has many connectivity libs accumulated over the years, and is able to produce cross-platform code.