NI TestStand

cancel
Showing results for 
Search instead for 
Did you mean: 

LabVIEW RTE patch version mismatch and adapter error

Hi,
I have a test system with all the VIs saved in LabVIEW 2013 SP1 f5. Recently I updated my PC (not test system PC) to use patch f6 and edited one VI with it. After transferring this VI to the test system, TestStand didn't want to run this code module (red exclamation mark). After mass compile on the test station PC, everything started to work again.

Does this mean that the VIs need to be saved in the same patch version to properly work?

I do not use auto detect of the RTE because it seems to be slower configuration. Is that true?

Michał Bieńkowski
CLA, CTA

Someone devote his time to help solve your problem? Appreciate it and give kudos. Problem solved? Accept as a solution so that others can find it faster in the future.
Make a contribution to the development of TestStand - vote on TestStand Idea Exchange.
0 Kudos
Message 1 of 4
(2,449 Views)

I doubt this was related to the patch issue.  My guess is that when you moved the VI from dev to deployment it broke the links with the subVIs.  Basically when you deploy TestStand the deployment utility relinks all of your VIs to their new relative locations.  If you later try to copy a VI like that it won't be relinked to the deployed location of its subVIs.

 

My 2 cents,

jigg
CTA, CLA
testeract.com
~Will work for kudos and/or BBQ~
Message 2 of 4
(2,420 Views)

I was not using deployment utility and I have absolute paths. I am not saying that the issue fixed by the patch was the reason of my problem, but the fact that the versions were different.

Michał Bieńkowski
CLA, CTA

Someone devote his time to help solve your problem? Appreciate it and give kudos. Problem solved? Accept as a solution so that others can find it faster in the future.
Make a contribution to the development of TestStand - vote on TestStand Idea Exchange.
0 Kudos
Message 3 of 4
(2,407 Views)

Minor or patch versions do not impact runtime version compatibility. Even in the case that a recompile is required to implement the fix (like CAR 473514 called out on the patch details page for f4), it should still be executable - it just won't have the fix. I'd expect any exceptions to this should be explicitly called out on the patch details page.

 

I agree with Jigg - if it was solved by a mass compile, this is likely an issue with some subVI linkage, or one VI somewhere set to have separate compiled code. There are ongoing efforts to improve how errors like this are reported, and hopefully avoid many altogether via the backwards compatible run-time engine in LV 2017 and later.

 

Trent

National Instruments

https://www.linkedin.com/in/trentweaver
Message 4 of 4
(2,391 Views)