MisMatch when UnFlattening

[CoastalMaineBird]

LV2013SP1, Win7

Having trouble understanding what's happening here.

I FLATTENED a copy of the V1 structure into a string and stored it in a file.

The string is shown at the left. (the original is in 6-pt font - it's also shown in HEX notation).

If I UNFLATTEN that string using V1 as the TYPE input, it comes back just fine.

V2 differs from V1 ONLY in the addition of the FILTER and FILTER FREQ item

CLUSTER ORDER is top to bottom, the SCALE FACTORS array is element #2 in both cases.

What I EXPECTED, when unflattening the string into a structure that's bigger than the original, was to get good data, up until the string ran out,  and then get FALSE / 0 / 0.0 / "" for the remainder, since there is no data to put there.

That's what happens if I unflatten a string containing { A | B | C | D} into a cluster with { A | B | C | D | E } - the A,B,C,D values come out OK, and the E value is default.

Here's proof:

But that doesn't happen if one of the elements is an array.

Why?

[Sam_Sharp]

As far as I can remember, the flatten/unflatten from string (just like the flatten/unflatten to XML) is not very robust at unflattening if the data types don't exactly match (i.e. mutation). Flattening/unflattening LV Classes can do this as they keep a mutation history.

When we have needed to do this, we have usually used the OpenG Variant Configuration File VIs as they tend be more robust in converting the data back into a LV type when there are missing items (you can specify default values for each item in the cluster if it doesn't exist in the data).

[Norbert_B]

My guess is that this behavior is kind of expected. Please refer to the LabVIEW help "How LabVIEW Stores Data in Memory".

I expect the array to be placed at the end of the structure, not "in place" as you expect it.

It seems that unflatten does not correctly re-create the handle to the array by putting the array to a valid location if the wired data type is not exactly what is flattened in the string.

I expect an unflatten by using the "correct" type (V1) will work. Does it?

Norbert

EDIT: Corrected some unclear items.

[Intaris]

What is the exact datatype of the items before the array?

IIRC Flattening to string serialises the data, the array should be in-line.

Shane

Ps Indeed, you can see the Boolean "01" for TRUE and the "0A" for 10 at the end of the flattened string.

[Norbert_B]

Shane,

if it really serializes the data, i concur with Steve that the behavior is unexpected. In that case, V2 should include/display the content of "Scale Factors" which it obviously does not.

The data elements before Scale Factors is not an issue because if V2 wouldn't match them, all elements AFTER Scale Factors would also mess up (e.g. Rec. Rate) as data alignment wouldn't fit anymore. That assumes that the default values of V2 don't by accident match what we see in the screenshots....

Norbert

EDIT: One VERY IMPORTANT ASSUMPTION: The tab order of elements of V1 and V2 is identical. So the two new elements are placed AFTER the other items (including the array)!. Is that true?

EDIT 2: The LV help contains some information on the TYPE DESCRIPTOR. Please verify if there could be some sources for that behavior you observe. Thanks.

[tst]

Everything should definitely be inline by definition, as this is flattened data, so even if it isn't so in memory, it will be when flattened.

Even so, what I find unexpected is that LV is actually gracious enough to allow the second case in the original post to work at all. It correctly throws an error, but I would also have expected it not to even try the conversion and to simply return the value in the type input. Edit - Thinking about it a bit more, I understand why it works - the flattened data does not include type data, so the only way to know if it works is to actually try to match the data and at that point I guess LV figures out it's better to leave the partial data in so you can see where it failed.

Regardless of whether or not this actually works, I would definitely suggest following Sam's suggestion from the first reply. Don't rely on this working for your actual code.

[Intaris]

Note that arrays and Strings which exist inside other structures (A Cluster here) will always have their lengths prepended.

Looking at the flattened data (A bigger image would help....) we can see the flattened data for:

00 = FALSE

4059000000000000 = 100 (DBL)

00000001 = Array size 1 (32-Bit)

0000000000000000 = 0 (DBL)

3FF0000000000000 = 1 (DBL)

0000000000000000 = 0 (DBL)

0000000000000000 = 0 (DBL)

0000000000000000 = 0 (DBL)

4059000000000000 = 100 (DBL)

0000000000000000 = 0 (DBL)

0000000000000000 = 0 (DBL)

But then I can't quite follow where the Strings are supposed to be.....  I don't see Hex values for "degC" Anywhere in the flattened string (And certainly not twice).   If I had to hazard a guess, I might suggest that the cluster V1 has some hidden elements in the cluster..... It seems to be storing a couple extra DBLs with zero value.

1E is the Calendar Interval 30 I presume, and as mentioned previously, the "0A 01" are 10 and TRUE at the end respectively.

PS: Ah I see a timestamp in there also.....

PPS, 4008 0000 0000 0000 is "3" in DBL, spotted just at the start of the fourth last line.

Are the "degC" Strings or something else?  Could they be u16 enums by chance?

[CoastalMaineBird]

I expect an unflatten by using the "correct" type (V1) will work. Does it?

Yes.  The example pic shows the same string unflattened into V1 (which works) and into V2 (which doesn't).

[Sam_Sharp]

---

@Intaris wrote:

But then I can't quite follow where the Strings are supposed to be.....  I don't see Hex values for "degC" Anywhere in the flattened string (And certainly not twice).   If I had to hazard a guess, I might suggest that the cluster V1 has some hidden elements in the cluster..... It seems to be storing a couple extra DBLs with zero value.

---

The units could be an Enum rather than a string?

[CoastalMaineBird]

What is the exact datatype of the items before the array?

As shown in the pic (cluster order = top to bottom), Item 0 is a boolean, Item 1 is a DBL (max value), item 2 is the array.

 the array should be in-line.

Which is what I expected, but that contradicts what Norbert said above.