Jump to content

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


Recommended Posts

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

Screen Shot 2017-10-31 at 3.25.14 AM.png

Link to comment

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).

Link to comment

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?

Link to comment
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.

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.