LabVIEW subscription model for 2022

[BertMcMahan]

Thanks Eric. So what is the difference functionally between a development license and a deploy/debug license? I understand the licensing terms are different, but can you actually view, edit, and rebuild exe's with a deploy/debug license?

Is there more info on what constitutes debug/deploy? I'd assume something like fixing a hard coded scale factor, changing a folder directory or IP address, etc. would be covered under deploy/debug. What about adding a new measurement feature, or adding a second brand's instrument? (For example, you originally code with an Agilent oscilloscope and want to add a Rigol oscilloscope)?

Is the distinction a licensing one only or a functional one, similar to running an executable with debugging enabled (where you can see all of the code and place probes, but you can't modify any of it)?

Thanks for the help. I've read the linked articles but I don't quite understand what a debug deploy license can actually do.

[Kevin_Price]

I expect you'll get a better answer from Eric tomorrow,

In the meantime, I worked in a facility about 10 years ago that had a small number of dev licenses and a large number of debug/deploy licenses for the several dozen similar-but-not-quite-totally-the-same sets of test apparatus.

The overall schema was a very flexible front-end "test definition" managed via Excel workbooks.  The core engine used VI scripting to auto-generate code according to that test definition and some specific coding conventions we adhered to.

The point being that executables under the run-time engine couldn't work due to the reliance on scripting which required the dev environment.  On the other hand, the team of developers amounted to only about 5 of us.

The solution (which, like the scripting schema, was already in place when I got there) was that the test stands ran using debug/deploy licenses while we used dev licenses in our cubes.  Debugging was sometimes done in place at the test sets.  Edits could be made at the test sets as well, but by both convention and practice, that was only when needing to fine tune debug/troubleshooting changes at the actual hardware.  Normally, all planned edits were done offline under dev licenses.

So all this stuff was in place well before I got there and I don't know all the fine details.  The way I recall a conversation with the "old-timers" there, they walked the plant with the local tech sales rep, talking through the workflow, usage, and #'s of actual developers vs.  # of systems needed a dev environment.

    The end result of that was lots of debug/deploy licenses with NI's blessing.   There were no dev environment limits or differences I knew of, it was fully featured.  The special licensing was granted based on some combo of trust, integrity, verification, and relationship.  That was when it was pretty common to have fairly long-term tech reps with whom one could develop a good working relationship, in our region anyway.

I never really knew the "hard limits" of the license agreement.  Because our practices were such that we were never trying to get near them anyway.  NI knew we had at least as many dev licenses as actual developers, knew we had far more dev deployment needs than developers, knew we had uptime incentive not to do normal development at the test sets, and had many years of history with the aforementioned old-timers.   (One of whom, BTW, was pretty involved in the founding info-labview, a *mailing list* that predated these forums by several years).  It was just kind of clear and logical that ours was a legit usage scenario for what NI intended to support & allow.

I *think* executables can be built as well.  We started working to transition the entire schema over to LabVIEW Real-Time.  Scripting still auto-generated a bunch of code modules, but these then had to be further compiled and deployed to the real-time PC.  We had a couple proof-of-concept instantiations.   Then the place shut down, closed its doors, and I ended up where I am now.  The end.

-Kevin P

[Tepig]

---

@RTSLVU wrote: LabVIEW Community Edition is "the bait" and the LabVIEW subscription model is "the trap".

---

Haha, I am the pearson who took the bait.

With Community Edition being free, I thought it could be used for programming education for students.

I had begun preparing for this. Since LabVIEW is graphical programming and, unlike Scratch, is used a lot in society and they can learn industry knowledge such as CAN, I thought I could tout it as "you can learn a technology that can be used in the workplace".

Subscription made me unsure if this idea was really a good one, as Kevin also mentioned in his footer message, because when they grow up, I can't say with confidence that LabVIEW is used a lot in society. Without a doubt, LabVIEW is a useful and great tool. But the cost is high; NI's policies change frequently. Everything is unstable.

I have devoted a lot of time to NI since I was a college student until now. Not because I had to, but just because I liked love LabVIEW and VeriStand, all NI product.

I am very much looking forward to what Eric has to share with us this time.

If there is a discussion at some user group or other place, I would like to participate even though my English is not good😘

[billko]

I suggest Eric open a new stick topic on this subject, free from earlier, biased posts, so we can have a clean post that we can point our companies to.  I don't mean forget what we said, but just so there's not a loooong trail of negative posts to bias the thoughts of the visiting VIPs.  We can respond to Eric's posts however, but at least he will have a legit chance at having his side of the story heard.

[Kevin_Price]

I'll second that!   Sounds both fair and potentially productive!

-Kevin P

[rolfk]

---

@BertMcMahan wrote:

So what is the difference functionally between a development license and a deploy/debug license?.

---

Technically there is none. It’s the same installer as the Professional Development system. And you can use it the same essentially. But it is not meant to develop applications with.

As the name says it is for debugging where you open, view and single step through code and make small modifications to fix bugs. In addition it can be used to run applications that for some reason can’t execute as build executable, either because they use for instance edit time scripting or a plugin architecture that requires source code access at runtime. Although these last two points could be solved with the full featured runtime too, but NI never documented in public how to get that properly installed and used on a target machine.

[WavePacket]

---

@Tepig wrote:

---

@RTSLVU wrote: LabVIEW Community Edition is "the bait" and the LabVIEW subscription model is "the trap".

---

...

Subscription made me unsure if this idea was really a good one, as Kevin also mentioned in his footer message, because when they grow up, I can't say with confidence that LabVIEW is used a lot in society. Without a doubt, LabVIEW is a useful and great tool. But the cost is high; NI's policies change frequently. Everything is unstable.

...

I am very much looking forward to what Eric has to share with us this time.

...

---

I am also looking forward to what Eric has to say too. As someone who is young, and had been making LV a professional development side gig, I am worried about exactly what you are too: high cost, instability of policy (including licensing & NXG). The subscription issue seems to lessen the likelyhood of small companies using LV due to worries about steady long-term costs, and small companies are how big companies start! 

As an added on question, I'd be curious if Eric could shed some light on how NI wishes to appeal to small tech companies, or if they are pivoting to larger companies as a strategy.

[WavePacket]

---

@billko wrote:

I suggest Eric open a new stick topic on this subject, free from earlier, biased posts, so we can have a clean post that we can point our companies to.  I don't mean forget what we said, but just so there's not a loooong trail of negative posts to bias the thoughts of the visiting VIPs.  We can respond to Eric's posts however, but at least he will have a legit chance at having his side of the story heard.

---

That seems a decent idea, as long as we link it in this thread so all interested parties can all get directed to the new location.

[billko]

---

@WavePacket wrote:

---

@billko wrote:

I suggest Eric open a new stick topic on this subject, free from earlier, biased posts, so we can have a clean post that we can point our companies to.  I don't mean forget what we said, but just so there's not a loooong trail of negative posts to bias the thoughts of the visiting VIPs.  We can respond to Eric's posts however, but at least he will have a legit chance at having his side of the story heard.

---

That seems a decent idea, as long as we link it in this thread so all interested parties can all get directed to the new location.

---

Of course we don't want to lose interested parties.  Then again, a sticky post is difficult not to notice.  😉

[EricR]

I like this suggestion.  However, if I make it "sticky" and create a new thread on it, there will likely be some guidelines I put in place around it.  In the meantime, I'm also likely going to entertain a healthy debate here in this forum with the people who have expressed interest.  I'm working on a "well articulated" summary.  So please stand by.  Rolf and others who are also in my LabVIEW Champions group have already seen a version of what I will reply with here.  Please don't take what I posted in our private forum and paste it here but you already know the details of what I will cover.

In addition, I do want to point out a few things that I'm working on in parallel.  I would like for you all to continue posting your concerns here.  Many of them have sparked some good debate with me and my colleagues.  I think a healthy amount of debate is always good, especially when a company has introduced change elements into an ecosystem, as NI has done in this case.