NI Labview Run-Time Engine 2014 Windows 10 compatibility

[ZoltanMTS]

Hi,

We have an old system, which has an application that is running on PC and communicating with a CompactRIO via Ethernet. The CompactRIO is fine, but we need to move the application to Windows 10. It was built on LV2014 and now it throws an error regarding instr.lib

What I would like to know is that if it is a missing file issue, so I can solve it by re-installing the Run-Time Engine or it is a compatibility issue, that is an application that was build under LV2014, cannot be run on Windows 10. The reason I am asking is that, the page about Windows 10 compatibility, which is here:

https://www.ni.com/en-gb/support/documentation/compatibility/15/national-instruments-product-compati...

says that NI LabWindows/CVI Run-Time Engine is compatible only from LV2015, but it does not say anything about NI Labview Run-Time Engine, so I presume it is Windows 10 compatible. Only double checking.

Thanks,

Zoltan

[RavensFan]

instr.lib is for instrument library drivers.  You'd have to give some more details about what the error is your are receiving.  Perhaps the library you are using has an underlying .dll that has an issue with Windows 10.

If your application is built on LV 2014, it is not that far away from a LabVIEW version tested to work with Win10.  That is LV 2015 SP1.  So your best action would be to take your application.  (Make a copy).  Load it into LV 15 SP1, fix anything that is broken or missing (probably not much).  Then build the application.  I just did that with a couple of my applications based on LV 2013 and had minimal problems.

[ZoltanMTS]

Thanks, we may have to go along that way, but the situation, as usual, is not that simple.

This is a 10-15 years old project, which was outsourced, as during the last 10-15 years, we have only 3-4 Labview projects. Then we moved Labview in-house and now I have source code of a couple of them, but not all. We may have this one somewhere, but it is not that easy to find, so we try to move the built code to Windows 10, as otherwise there are no reasons to re-build it.

Another issue is that, I am sitting in Europe, my colleague prepares the whole system, including the CompactRIO, in the US, which will be shipped in a day to Japan, where we will be able to carry on as part of the full installation, but it will cost extra time for us on-site.

At the moment, it seems it is a driver issue, I was told the actual error message is “Searching for instr.lib when loading nisyscfg.dll    … LabVIEW: Resource not found”.

My colleague will try to re-install the drivers, which may solve the problem, but may cause another one: for Windows 10, we have to use any version between 14.5 and 17.6, if the software was built in LV2014 SP1. If it was LV2014, it is version 14 only, which is not W10 compatible, so we are not lucky.

https://www.ni.com/en-gb/support/documentation/compatibility/17/ni-rio-and-labview-version-compatibi...

If we are luck, we have to install version 17.1 on the PC, as that is the only W10 and LV2014 SP1 compatible version:

https://www.ni.com/en-gb/support/downloads/drivers/download.ni-compactrio-device-drivers.html

I am sure we will be able to manage to do that somehow, we may have to install the Japanese driver version, but that should not be a problem. The issue I expect is that, when I use the full development environment, the driver versions on the PC and the CompactRIO should match, which can be the case with the Run-Time Engine module also. And that is where we start walking down in the rathole, as that means that, we have to update the driver on the CompactRIO, which may throw a potential compatibility issue between the built software and the driver on the CompactRIO.

So the supplementary question is that, if the change of the driver on the CompactRIO can cause any compatibility issues with the software already on the CompactRIO or the driver can be changed (upward) freely?

Thanks,

Zoltan

[RavensFan · Accepted solution]

I'm sorry you are in this hole of trying to make 10-15 year old code, work in a 6 year old programming environment, on a computer with a 4 year old operating system and then dealing with a Japanese PC which often will give you language issues that a foreign language European PC wouldn't give you.

But this is the kind of thing that should have been foreseen and worked out much longer ago with all the equipment in the same room than a day before the equipment ships.  And you are right that will cost extra time on-site.  And there are generally pressures to get things done quicker when on site and without being in the comfort zone of your own work environment, it can make it much more difficult to work through issues with a clear head.

I don't suspect you'll have issue upgrading the cRIO drivers.  It's something you'll do through measurement and automation explorer.  Make sure you have all the device drivers installed on the PC that will be connecting to the RIO when on-site.

Actually, rereading your message, I'd be concerned with you saying you don't have source code.  If the RIO's code (real-time and/or FPGA) was built on an older version of LabVIEW, then if you update the drivers on the RIO to a newer version, the RTEXE and/or FPGA bitfiles would probably need to be recompiled for that newer version.  If you don't have the source code for them, I don't know how you'll accomplish that.

Good luck!

[ZoltanMTS]

Thanks for your replay.

---

@RavensFan wrote:

I'm sorry you are in this hole of trying to make 10-15 year old code, work in a 6 year old programming environment, on a computer with a 4 year old operating system and then dealing with a Japanese PC which often will give you language issues that a foreign language European PC wouldn't give you.

---

This is actually a quiet standard situation for us, as costumers upgrade systems only after 10-15 years and sometimes it is difficult to find someone who saw the system and even more difficult to find someone who knows it, but eventually we sort things out.
The source code most probably exist somewhere: the company that developed it for us is still around and we normally delivery source code to costumers, but it will take time to find it.

Thanks for your reply,

Zoltan