Error 116 occurred at Flattened String To Variant in Array of VData to VCluster__ogtk.vi

[Michael Aivaliotis]

At a high level, I'm taking an array of variant data and trying to convert it to a variant cluster using the openg variant tools. However, I'm getting a low level error, and not sure why. I'm using the "Array to VCluster__ogtk.vi". Now the variant array has 997 elements. Could this be the reason? Is there a limit?

Quote

 

Error:

Error 116 occurred at Flattened String To Variant in Array of VData to VCluster__ogtk.vi->Array to VCluster__ogtk.vi->Untitled 9.vi

Possible reason(s):

LabVIEW:  Unflatten or byte stream read operation failed due to corrupt, unexpected, or truncated data.

 

I've attached the LabVIEW 2014 VI with the data as a constant so you can run it yourself. You'll need the OpenG variant tools installed.

Untitled 9.vi

[bbean]

I think the U16 length is overflowing.  Not sure what to do about it though.

 

Edited October 31, 2017 by bbean
image update

[drjdpowell]

I think your hitting one of the limits of the pre-8.0 type descriptors that OpenG uses.

[hooovahh]

I've been avoiding these functions since they are much less efficient than the variant to data functions.

I made an XNode that you wire an array of variants to, and it will turn it into the cluster you told it.

Of course if you don't like XNodes not written by NI you can do this normal VI that converts the array of variants, to a cluster variant, which variant to data can turn back into the cluster.  Note that VI has a bug where clusters of size 2, 3, 4, or > 50 elements don't work properly.  Also the Idea Exchange where  Database Variant to Data function seems to do the same thing (also an XNode but by NI).

[Michael Aivaliotis]

After I woke up this morning, and had a coffee, I did some probing and came to the same conclusion. We have a roll-over situation on the U16\I16 combo for the array length math.

So digging into the type descriptors doc in the LabVIEW help (which I never thought I would have to do today), it seems that there are two formats (7.x and 8.0). OpenG uses the 7.x format I assume. So is this fixable by updating how OpenG handles type descriptors and making it use the 8.0 format? Or is it more than that?

[drjdpowell]

It should be possible to update the OpenG VI, but why are you working with such a monster as a 997-element cluster in the first place?

[Michael Aivaliotis]

10 minutes ago, drjdpowell said:

It should be possible to update the OpenG VI, but why are you working with such a monster as a 997-element cluster in the first place?

Well, I've found a workaround to the above problem in the meantime. But to your question, this cluster doesn't physically exist. This is dynamically generated from various sources. I then pass the variant data into another function that processes it into a specific file format. So it's a means to an end. The data size is simply a factor of a lot of configuration parameters.

This is an old app. Probably, if i was to redo it, I would take different approach. But it is, what it is.

[drjdpowell]

You should see if the next function along can be easily made to work with Array-of-Variant in place of Variant Cluster.  Most of my subVIs that take Variant Clusters convert internally to Array-of-Variant form anyway (using the Variant to Date primitive).