Error 116 unflatten from string on cRIO

[wrkcrw00]

I have a console (Windows PC) sending configuration data to a cRIO. The data starts life as a variant (with attributes). I flatten the variant to a string then send it via an STM message to my cRIO. When I unflatten the string back to a variant, I get error 116 (LabVIEW:  Unflatten or byte stream read operation failed due to corrupt, unexpected, or truncated data.)

As a check, I sent the flattened variant via STM message in a loop from console back to itself just to verify the STM Server/Client didn't corrupt anything and it worked fine. 

As a second check, I probed the unflattened string on both the console loop back check and the cRIO. Both strings are identical, so it appears the data makes it through the STM messaging correctly. It fails at the unflatten from string on the cRIO only. 

Is there some constraint on the cRIO with unflattening? 

[majoris]

Your second check seems to show that the messaging is working correctly, but what about the representation on the cRIO? If you flatten a variant composed of the same data on both cRIO and your console, do they produce the same string? I've never worked with cRIO so I don't know how it works, but perhaps somehow the runtime on the cRIO flattens/unflattens data differently than your console and this should be something you can directly check.

http://digital.ni.com/public.nsf/allkb/B4CA815D8B5FCEEB862579B100695147

Also posting some relevant code is helpful to ensure nothing obviously wrong on the block diagram is happening.

[crossrulz]

---

wrkcrw00 wrote:

Is there some constraint on the cRIO with unflattening? 

---

It very well could be the RT handles variants differently.  My first thought was you were using different versions of LabVIEW between the cRIO and Windows application, which would also cause issues with flattening variants.

My suggestion would be to use a cluster instead of the variant.

[wrkcrw00]

I found the issue. It's not a problem with unflatten from string used on a cRIO. What I didn't realize is that a variant stores not only the data that was converted to a variant, but also the type of that data. The types of data I store in the attributes of the parent variant (the attributes themselves are variants) are classes. Since these attributes are stored as variants, the class types are stored. On the target, I hadn't deployed all of the classes I had used in the variant. LabVIEW apparently does a check when the variant is unflattened from the string. Since it could not find all of the variant types (i.e. class types) in memory on the cRIO, it threw error 116. 

All I had to do was add the two classes I hadn't yet added to the cRIO target on my project and it worked.

[Mark_Yedinak]

---

@majoris wrote:

Your second check seems to show that the messaging is working correctly, but what about the representation on the cRIO? If you flatten a variant composed of the same data on both cRIO and your console, do they produce the same string? I've never worked with cRIO so I don't know how it works, but perhaps somehow the runtime on the cRIO flattens/unflattens data differently than your console and this should be something you can directly check.

http://digital.ni.com/public.nsf/allkb/B4CA815D8B5FCEEB862579B100695147

Also posting some relevant code is helpful to ensure nothing obviously wrong on the block diagram is happening.

---

LabVIEW handles all of its data using network byte ordering (big-endian) so that you can seamlessly share data in LabVIEW on different platforms.