NSV cluster or variant data type not able to be read on all systems/LV versions

[toddy]

We have a network shared variable which is a cluster cast to a variant which we can read on most PCs in our office using executables built in LV 2012 or 2014. On other machines it can only be read using executables built in LV 2014, not 2012. Other shared variables that have more simple data types can still be read on these troublesome PCs in either LV 2012 or 2014.

In short the problem is limited to particular PCs running executables built in LV2012 reading network shared variables of a particular data type.

Does anyone have any ideas? We really need this to work as part of a much bigger application which is built in LV2012.

[Sam_Sharp]

If the cluster/type definition is different between the different applications then it will fail when converting the data. I also don't think that LabVIEW guarantees it will be able to convert variant data for different LabVIEW versions (i.e. the underlying implementation of converting to/from a variant might change, breaking compatibility).

Your options are:

1) Keep the different versions of the cluster in each application and try to use 'variant to data' on each one until it succeeds

2) The OpenG/MGI toolkit has functions for determining the type of data in a variant so you can use this to read out individual elements from the cluster or at least determine its type

3) Don't use variants in NSVs - convert the data to a string according to a known protocol and then decode it at the other end. JSON would be a prime example. Unflatten from XML has the same issue as variants unless you read out the individual elements. You could also use the Variant Configuration File as this will use default values for any missing items.

[toddy]

Thanks Sam,

At the moment it looks like it is a problem with the LV2012 runtime and a cluster that has nested type defs. We're running more tests now to try and get to the bottom of this behaviour.

[toddy]

Just for info, this turned out to be a bug with the 2012 runtime which is fixed in 2012 SP1

[Sam_Sharp]

Argh! I knew there was a bug with LV2012 on RT that would cause RT executables to hang on startup if there were NSVs based on a type definition but I didn't know of any other issues with NSVs in 2012.