"Unflatten From XML" Does Not throw an error every time when there is a Data Type mismatch

[Omar_II]

Using VI Server to set the controls of a VI where the Control data is stored in XML.

But if there is a Data Type mismatch the "Unflatten From XML" does not throw an error every time, but only every OTHER time.

Simplified to isolate the problem. (Most of our data type are clusters, but the error is the same or lack of errors)

(The I32 reference did not transfer correctly in the snippet)

I would expect the 1106 error every time not just every OTHER time.

Seen in LV 2013 and LV 2014

[Omar_II]

Work around? But it means I have to try twice for every Unflatten From XML just to verify the data types match.

[DJColeslaw]

I'm not sure why, but it appears to be lined to the way you're providing the type to the unflatten from XML VI.  If I create a numeric constant and set the data type as i32 and then run that into the unflatten from XML vi it throws an error every time.  You could even just wire your I32 indicator into the type since it's not being used for anything else.  

[Omar_II]

You are right if in my actual application I have the actual control to work with, but I don't.

The example I posted was a VERY simplified example to reproduce the "bug"

In my actual application I am dealing with all dynamic loaded VIs so I never actually have any of the actual Controls.

All I ever have are the variant data.

If I was only dealing with simple data types (int, float, string, Boolean, etc) I could do as you say.

But I have clusters and arrays that I do not know their data types until run time.

Without an error at the correct point, it makes it very hard to debug the test sequence.

My work around is posted in the 2nd post is to always unflatten twice.

NI has reproduced problem and will get back to me. I will post their reply

[Omar_II]

Corrective Action Request (CAR) 523361 has been filed with R&D

[Omar_II]

Re: CAR 523361

I got a reply from NI ...

---

Paolo Fu wrote:

I have heard back from R&D and they have said that the reason that it is happening every other time is because the formatting is not correct. The correct formatting would be:
<LvVariant>
<Name>Variant Data</Name>
<I16>
<Name>I32</Name>
<Val>1234</Val>
</I16>
</LvVariant>

instead of:

<I16>
<Name></Name>
<Val>1234</Val>
</I16>

I have tested this and have confirmed it on my end.

Regards,

Paolo Fu
National Instruments
Applications Engineering
http://www.ni.com/support

---

BUT! I say if the "Unflatten From XML" requires the <LvVariant> tag to unflatten to a Variant data type then it should throw an error any time there is not the correct <LvVariant> tag. Not just every other time.

If the data types DO NOT MATCH then they do not match, therefore ERROR!

[NateBraska]

Hi Omar,

I recommend concatenating the <LvVariant> tags to wrap your current XML string input. This implementation results in an error on each iteration, if the numeric datatype does not match, like expected.

Your application can change the middle element of this Concatenate Strings function. This is necessary since the output of the "Value" Property Node is a variant when its reference has been cast to the more generic Control reference type. I also think this will be faster and more robust than running two iterations of the Unflatten From XML VI.

Paolo has filed CAR 523361 for the issue with errors on alternating iterations, and NI R&D will prioritize it accordingly. Please continue to work with Paolo if you have any further questions with implementing a workaround.

Best Regards,

Nathan Burke

Product Support Engineer | LabVIEW R&D | National Instruments | Certified LabVIEW Architect

[Omar_II]

---

@NateBraska wrote:

I recommend concatenating the <LvVariant> tags to wrap your current XML string input. This implementation results in an error on each iteration, if the numeric datatype does not match, like expected.

---

That is exactly what I implemented after getting the reply from R&D, but I first check that the XML string does not already start and end with the <LvVariant> , </LvVariant> tags.