LabVIEW subscription model for 2022

[benjamin-hinrichs]

---

@stevesteve wrote:

Back onto Labview; you can still buy the perpetual LabVIEW Professional Development System.

Part number:  776678-35WM

Available from your local NI sales rep (not online).

---

You already posted that! And I handed out kudos both times; so thanks! 😁

[crossrulz]

---

@benjamin-hinrichs wrote:

---

@stevesteve wrote:

Back onto Labview; you can still buy the perpetual LabVIEW Professional Development System.

Part number:  776678-35WM

Available from your local NI sales rep (not online).

---

You already posted that! And I handed out kudos both times; so thanks! 😁

---

NI is supposed to be pushing the Debug and Deployment License for a perpetual license.  The part number is 781866-35, as seen here: LabVIEW Product Page.

[1100fps]

So it's possible to purchase a perpetual license, but there is no license maintenance to keep current?

The question is likely academic, as we have frozen or base at V21.

[Intaris]

We are also starting to hear directly from customers (research / Industrial and academic) that they are just dropping LabVIEW due to the switch to a subscription license. Most are just using Python, some are switching to MATLAB.

LabVIEW is dying right in front of our eyes. Whatever cash-flow increase NI is hoping for is going to be very short-term. If things continue like this, LabVIEW is in dire trouble.

Without exposure to LabVIEW in research, future market impact will be significant. Once Universities stop using LabVIEW internally, they stop teaching it. And if they stop teaching it, LabVIEW becomes more and more obscure. This is not a cash-flow problem at the moment, it's undermining any furture interest, a much more damaging enterprise. While I'll freely admit I'm not a sales guy, this strategy by NI seems insane.

I've even started thinking NI has been infiltrated by people from the competition pruposefully trying to destroy their market. That's how much trouble I have understanding NI's choice of course here.

[Pnt]

---

@Intaris wrote:

I've even started thinking NI has been infiltrated by people from the competition pruposefully 

---

I think your thoughts went too far.

The reality, usually, is much simpler.

Those things happen, when managers, prevail. Managers who are very good at nice speeches but know very little about development and about real life.

And this usually happens when a company is getting bigger... managers prevails... and engineers voice is lost...

So NI got bigger...

...but the future is dark. Which serious engineer would select to program in a language, in which he will not have access (to his own programs!), if he will stop paying.

[Gribo]

Here is a bit more to the conspiracy theory - the new PXIe DMMs no longer use VISA & SCPI as their interface, they use proprietary APIs. DMM SaaS anyone? They have already did it for their high end VNA and RF signal generators. 

[crossrulz]

---

@Gribo wrote:

Here is a bit more to the conspiracy theory - the new PXIe DMMs no longer use VISA & SCPI as their interface, they use proprietary APIs. DMM SaaS anyone? They have already did it for their high end VNA and RF signal generators. 

---

There are actually a couple of things happening there.  NI has been fairly open that they are trying to move their drivers to a gRPC interface.  Removing the VISA interface (I didn't think they had a SCPI interface) would be a move in that direction.

[CyGa]

Going gRPC over-complexify things when doing local dev (even more on a PXI chassis with an embedded controller).

And it breaks compatiblity with legacy code.

Adding gRPC is what they are advertising, not replacing one by the other !

[cbutcher]

---

@crossrulz wrote:

---

@Gribo wrote:

Here is a bit more to the conspiracy theory - the new PXIe DMMs no longer use VISA & SCPI as their interface, they use proprietary APIs. DMM SaaS anyone? They have already did it for their high end VNA and RF signal generators. 

---

There are actually a couple of things happening there.  NI has been fairly open that they are trying to move their drivers to a gRPC interface.  Removing the VISA interface (I didn't think they had a SCPI interface) would be a move in that direction.

---

I haven't checked any of this, but my questions would be

• What is this "proprietary API" (to Gribo) and
• Do they now have a gRPC interface?

If the current state really is a black box, and the edge of that box is not an open/discoverable system, then that's somewhat worrying.

But SCPI and VISA are functionally just interfaces to what at a lower level is a black box, so if the new interface is gRPC, then I'd put that in the "no change here" box... (maybe even an improvement, since I'm not sure how discoverable SCPI/VISA have to be, and I think gRPC protocols have at least a chance of being "self-documenting" (so long as it's not hidden inside something less transparent...)

[Gribo]

Here is the relevant LAVA thread: Using VISA Find Resource for PXI Devices - Hardware - LAVA (lavag.org)