From Friday, April 19th (11:00 PM CDT) through Saturday, April 20th (2:00 PM CDT), 2024, ni.com will undergo system upgrades that may result in temporary service interruption.

We appreciate your patience as we improve our online experience.

LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

I am having trouble connecting a LV2011 application to an application built in LV2014

I have 2 applications working together correctly in LabVIEW 2011 and LV2014...

BUT when I upgrade only one end to LV2014...

It seems to fail decoding any cluster or control passed from either end...

No code logic has been changed from the running LV2011 app other than importing into the newer release...

 

The RT code is running on the cRIO 9025 controller...

The MyComputer app is running on a Win7 PC... 

 

Adrian...

0 Kudos
Message 1 of 7
(2,712 Views)

Let me see if I understand you correctly.

 

You have an application that has a target VI running on a cRIO and a host VI running on your PC.  If both VIs are in LabVIEW 2011, everything works.  If both VIs are in LabVIEW 2014, everything works.  If you split them up so that one runs on LabVIEW 2011 and the other runs with LabVIEW 2014, you run into errors.

 

Is that correct?  If so, what is the operational need to run on different versions?  I'm more curious than anything.

 

Are you using shared variables to pass data between the target and host or are you using DMA buffering?  If you're using shared variables, are they set to be local to the project or are you deploying them configured to be accessible by multiple projects?  If they're local to the project, you're likely running two different projects in order to maintain the split between the versions of LabVIEW.

0 Kudos
Message 2 of 7
(2,671 Views)

You understand correctly regarding the successful connections...  11<->11 or 14<->14...

We have hundreds of LV2011 released devices and cannot expect customers to upgrade fleets of devices all at the same time...

Any PC app can connect to 40+ RT nodes at any 1 time...

 

So we need to be able to upgrade individual devices (RT or PC) in a way that we have a manageable upgrade path for customers...

We do not use networked variables nor DMA buffering between devices...

Every connection is TCP/IP and UDP with conversions to/from string used extensively to send data in either direction...

At the UDP level I seem to be able to transfer some simple clusters between versions using the native flatten and un-flatten to/from string functions...

 

At the TCP level nothing seems to work? 

 

0 Kudos
Message 3 of 7
(2,629 Views)

Have you tried using two PCs to see if you can get a connection with one on 2011 and one on 2014?  If it errors there as well, there was likely a change in how TCP was handled.  You can troubleshoot this easier from two PCs.

 

If that still works, it's more interesting that the two aren't talking.

0 Kudos
Message 4 of 7
(2,625 Views)

Thats what I'm doing now...

un-successfully... hum-bug...

0 Kudos
Message 5 of 7
(2,618 Views)

I found reference to a native variant conversion VI....

VI.lib-> Utility -> VariantFlattenExp.vi...

 

It is supposed to handle version compatibility...

Looking to see if a variant is converted anywhere that might need this for backwards compatibility...

 

But I didn't expect any changes to the non-variant <-> string functions...

 

So far I haven't found the culprit in my code...

0 Kudos
Message 6 of 7
(2,614 Views)

Yea that's the function you want to use.

 

Here's screenshots of Slides 15 and 16 from the presentation on this page: https://decibel.ni.com/content/groups/hidden-gems-in-vilib

FlattenToStringExp.PNG

FlattenToStringExample.PNG

 

Basically the Flatten To String functions will change bytcode implementations between LabVIEW versions, you have to use this function to avoid that!

Craig H. | CLA CTA CLED | Applications Engineer | NI Employee 2012-2023
0 Kudos
Message 7 of 7
(2,605 Views)