LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Caution - LabVIEW 2019 VISA Runtime Engine is not available yet

Solved!
Go to solution

While it is a little trickier in the case of DAQmx, where each new version supports new hardware so if you use a spiffy new DAQ card or something you may have to install the greatest and latest DAQmx, there is absolutely no need to install NI-VISA 2019 runtime just because you use LabVIEW 2019. The NI-VISA API is very stable since over 15 years and LabVIEW has no specific version dependencies on the latest and greatest NI-VISA interface. There is a very small chance that the NI-VISA 2019 runtime fixes some problem with specific computer systems, but generally even the NI-VISA 2016 runtime will simply work with a LabVIEW 2019 executable. 

Rolf Kalbermatter
My Blog
0 Kudos
Message 11 of 29
(1,295 Views)

@rolfk wrote:

While it is a little trickier in the case of DAQmx, where each new version supports new hardware so if you use a spiffy new DAQ card or something you may have to install the greatest and latest DAQmx, there is absolutely no need to install NI-VISA 2019 runtime just because you use LabVIEW 2019. The NI-VISA API is very stable since over 15 years and LabVIEW has no specific version dependencies on the latest and greatest NI-VISA interface. There is a very small chance that the NI-VISA 2019 runtime fixes some problem with specific computer systems, but generally even the NI-VISA 2016 runtime will simply work with a LabVIEW 2019 executable. 


That's nice to know, since that is not at all conventional wisdom concerning the LVRTE (new backwards-compatibility features notwithstanding).

0 Kudos
Message 12 of 29
(1,291 Views)

Are you talking about the NI-VISA Runtime Installer here or the LabVIEW Runtime Engine? They are very different beasts. If you compile a LabVIEW executable in LabVIEW 2019 then you need to have the LabVIEW Runtime Engine 2019 installed on every target computer.

 

The NI-VISA Runtime Installer is a different beast. That is a completely seperate API that is independent of LabVIEW and there has been very little change in that API in the last 15 years.So older VISA versions will generally just run fine with newer LabVIEW versions without any problems. There might be an esotiric API for things like USB support that might not be supported by very old VISA versions but otherwise the VISA version is pretty independant of the LabVIEW version. You do need a VISA version that supports your current OS version though, so a seriously older VISA version might have trouble to run under Windows 10.

Rolf Kalbermatter
My Blog
0 Kudos
Message 13 of 29
(1,285 Views)

@iannicholson wrote:

So I should be building a bare installer and a full installer with each EXE update? Sometimes I build 8 or 10 updates in a day! Seems like a lot of extra packaging for something that's rarely needed (but very important when it is).


This is generally how we build are applications. One installer is for an initial installation and the other is for the application only update. Makes distribution much easier. Also, you don't need to build the installers every time you build your application. Only build the installers for released versions. Or are you saying that you build 8 to 10 releases a day. That sounds like a process issue.



Mark Yedinak
Certified LabVIEW Architect
LabVIEW Champion

"Does anyone know where the love of God goes when the waves turn the minutes to hours?"
Wreck of the Edmund Fitzgerald - Gordon Lightfoot
0 Kudos
Message 14 of 29
(1,274 Views)

@Mark_Yedinak wrote:

@iannicholson wrote:

So I should be building a bare installer and a full installer with each EXE update? Sometimes I build 8 or 10 updates in a day! Seems like a lot of extra packaging for something that's rarely needed (but very important when it is).


This is generally how we build are applications. One installer is for an initial installation and the other is for the application only update. Makes distribution much easier. Also, you don't need to build the installers every time you build your application. Only build the installers for released versions. Or are you saying that you build 8 to 10 releases a day. That sounds like a process issue.


I guess 8-10 sounds like a lot. Really what happens is I send the app installer to my customer and they (or I, remotely) install it. Say they have an issue; I build a new .EXE and need to get it to them. I have a post-build action to generate my installer, so I just send them that instead of the .EXE. Then the process may repeat a couple or a few times (or not if I've done my job correctly Smiley Wink).

 

I could expound on the build to generate two types of installers. But this seems like a lot of work for little benefit. It's almost like including Windows 10 in the installer since that may need to be installed on the customer's PC too.

 

As it is, we only instruct the customer to install the runtimes (or again, do it ourselves remotely) when there's a major failure (new PC, wiped HDD/SSD, etc). Since the .EXE can change multiple times a day, but the runtimes change only every couple-few years, why build them into the install package at all? They are usually one-and-done.

 

I suppose the problem comes from those customers who are not online, or those who can barely operate a computer. Until this point the runtime installers have both been reasonable sized and simple .EXEs. I'm just not understanding why we now have to send out the full package instead of the runtimes, and hope these customers can safely de-select all the non-runtime stuff.

0 Kudos
Message 15 of 29
(1,267 Views)

Your reasoning isn't entirely consistent. The VISA Runtime has always been a several 100 MB download. You claim to care about the people who are not online or the noobs who barely are able to operate a computer, but think it was easier for them if you point them to a downloadable runtime installer they have to install themselves than including it all in one installer program. That doesn't exactly sound convincing. Also your release process would indicate that you have basically externalized the real testing of the software to the customer who gets a new executable and then can report back to you if it works. It's a development model of course that can work, especially if you create one different application for every customer rather than one application for multiple customers, but it isn't necessarily the most effective approach.

Rolf Kalbermatter
My Blog
Message 16 of 29
(1,244 Views)

I'm not boasting that this is best practice for most development cycles. We operate a very short feedback loop with our customers, mainly because I don't have the resources here to replicate every scenario that comes up in the field. Often the only testing I can do is by sending the update to the customer. The vast majority of the time this works great, but on occasions where I need to send corrective updates, it's a complete waste of time (and bandwidth) to bundle the runtimes.

 

I'm not sure why everyone keeps saying "just bundle the 1.5GB of runtimes with every app update". Can you point me to any examples of software that wasn't shipped on physical media that included all the runtimes in the download package? At one time this may have made sense with the .NET 2.0 runtime (for example) because it was only 22MB. But no downloadable software contains the whole .NET runtime at this point. It is listed as a prerequisite, and you install it before the fact. That's what we do with the NI runtimes.

 

Here's a for-instance:

We send PCs with our machines, and these PCs need to be set up. The runtime engine takes time to install (a lot of time until recent SSDs have taken hold), so we install runtime engines. We install 2009, 2013, then 2017 (8.6 was installed prior to any of those until a year or two ago). We need to be able to run one of several generations of our application depending on the machine's age, so we need runtimes for each (this should get easier now that the RTE can be backwards-compatible). This needs to be done in order because installing an older runtime after a newer one can cause very strange problems (spent hours on-site diagnosing that one).

 

Imagine bundling the runtimes with the program. The first time you install one, say with a recent runtime, everything probably works fine (minus the downtime during the installation). But if a mistake was made, or the PC gets repurposed, you can no longer install software for the older machine because there's a high probability that it will corrupt the RTE. So what do you do, wipe the drive and spend hours setting it up again fresh so you can install the older runtime? Thus we de-couple the runtimes from the app itself.

 

I know this use case differs a bit from sending everything to the customer and having them do it, but the sheer variety of machines, PCs, and software in our line of business mean that this needs to be dynamic.

0 Kudos
Message 17 of 29
(1,221 Views)

Why can't you create two installers?

 

First installer, just installs run-times (LabVIEW, VISA, DAQmx, other stuff whatever is needed.  Full version with configuration support or just run-times.)

Second installer, just installs your application.

 

For new users, send both.  The install the first one as a prerequisite (like your .NET example).  Then they install the second to get the program.

Existing users, just install the second.

 

Update the program?  Just update the second installer and send it to them.

 

I find many times if I update an executable, I'll just copy and paste it over the one that already is there.

0 Kudos
Message 18 of 29
(1,207 Views)

@RavensFan wrote:

I find many times if I update an executable, I'll just copy and paste it over the one that already is there.


That's all I have ever had to do.

========================
=== Engineer Ambiguously ===
========================
0 Kudos
Message 19 of 29
(1,199 Views)

@RavensFan wrote:

Why can't you create two installers?

 

First installer, just installs run-times (LabVIEW, VISA, DAQmx, other stuff whatever is needed.  Full version with configuration support or just run-times.)

Second installer, just installs your application.

 

For new users, send both.  The install the first one as a prerequisite (like your .NET example).  Then they install the second to get the program.

Existing users, just install the second.

 

Update the program?  Just update the second installer and send it to them.

 

I find many times if I update an executable, I'll just copy and paste it over the one that already is there.


This is exactly the method I used to use. But when LabVIEW 2013 came out, and I built an installer (through LabVIEW) which contained only the two runtimes we needed, it no longer included the "Deployable License" component (or it was a new requirement). After a bit of research, I gave up and started distributing both of NI's installers (LVRTE2013std.exe and visa540_runtime.exe) for the two runtimes, and having everyone run one and then the other. This was fine even if it was a little harder to explain.

 

When we switched to LabVIEW 2017, I assumed this was still a problem (I still can't find anyone else who noticed the problem). So I just send out both runtime installers just the same. This also worked fine.

 

Now, it seems NI doesn't provide these single-package installers, so I'm on the hunt for the next method I guess. I tried the original option (building a runtime installer through LabVIEW), and will be trying it out to see if the problem reoccurs. Hopefully it was a glitch back in 2013? Otherwise, and the point of this thread is, it doesn't really make sense that we now have to send out the entire NI-VISA package just to get the runtime out of it.

0 Kudos
Message 20 of 29
(1,173 Views)