LV 8.0.1 Bug, no error when unflattening mis-matched data type

[Swamp Thing]

When unflattening a string and wiring a "type" that does not match the original format of the data, sometimes I don't get an error and I get no data. I've attached a VI written in 8.0.1 that illustrates 2 examples of this. In LV 7.1 these cases did return an error, but not in 8.0.1. Can anyone offer some insight or global solution?
Thanks, Chip

[Swamp Thing]

More bad behavior...When Unflatten is called twice in a row, once with flatted data that matched the defined "type" then again with data that does not match, the second iteration returns the data from the first iteration and does not issue an error...any help???? See attached VI for illustration.
Thanks, Chip

Message Edited by Chip Jones on 05-24-2006 03:44 PM

[JeanPierre]

I don't have LV8 so I can't read your VI but usually, once data is flattened to a string, the type is gone. Unfaltten will perform a type cast on the string, whatever was the original type of the data. For example, a 8 byte string can be unflatten to a DBL, two SGL or U32, 4 U16, etc. without generating conversion error. A Conversion error will occur when the string is too short to fill the tasrget type.

[Swamp Thing]

Thanks JeanPierre. I've attached these VIs saved for version 7.1. You can see that errors are trapped here, but these VIs in LV 8.0.1 don't trap the errors. The problem is that in our application, we don't always know the structure of the incoming flattened string, and we rely on these errors to direct us to the proper data type of these strings to original data type. Without these errors to guide the way, our code becomes buggy, and the work-arounds are painful and clumsy at best. From the sound of your description, this was, perhaps, not the most robust way to go, but here we are.
Thanks again,
Chip

Message Edited by Chip Jones on 05-24-2006 09:14 PM

[GuenterMueller]

Hello Chip, you are in good company ("From the sound of your description, this was, perhaps, not the most robust way to go, ..."). I have been doing very similar things in one application.

Having looked at your code I would expect this to be a bug.  Or in other words: I really hope, that this is no "feature". Maybe someone from NI would like to add an official statement?

Thanks for your contribution, Chip. I did not recognize this until now.

Best regards, Guenter

[tst]

I can't see the code, but in general, there have been serious changes to the way LV represents and flattens data types in 8.

In general, relying on an error in an unflattening operation to correctly determine the data type sounds like a bad idea to me, because you have no way of being sure that there will be an error and you're relying too much on the internal representation of the various types, which might change.

A common way around this is to create a protocol - the sending side will identify what kind of data it wants to pass (for example, by appending a string of a fixed length to the beginning of the message) and the receiving side will read that part of the string first and know how to unflatten the data. This way you can pass arbitrarily complex structures and not worry about using trial and error. You can search the site for "messaging protocol" to see a nice tutorial implementing a similar approach.

[Swamp Thing]

Thanks for all of your input, everyone. I totally agree that simply relying on errors is a bad way to go, and putting a header on the string is more robust. In fact, we have moved toward this method in other areas of the code, but we have to consider version control and legacy issues when reading old pieces of data. The bummer is that the behavior in LabVIEW has changed, and we are having trouble recovering from this change. Even worse, incorrect data is being returned with no warning at all (see my 2nd post).
Thanks again,
Chip

[GuenterMueller]

Hello tst.

I agree to you that relying on the error out indicator is not always a good idea and especially that the unflatten from string function is a good example to your comment.

On the other hand: One of JeanPierre's VI tries to unflatten to an array of strings - and the input string cannot be converted to an array of strings. Why does the funcion output nonsense on nonsense input?   For situations like this I use the error out indicator every day in my code  and  I stay with what I said: I expect this to be a bug.

Best regards, Guenter

[tst]

In general, I agree with you and I simply forgot to say so in my last post. However, I don't have 8 and I don't know the extent of the change made to the flattening function in 8, like what kind of error checking it now performs. The fact that you're recognizing data as nonsense does not mean that LV can do that as well.

Basically, a flattening operation should be more than a simple typecast, so I would expect LV to be able to do good typechecking, but if (for example) it stores array data without keeping the type then it could recognize your string as an array, but it wouldn't recognize that it should be an array of numerics and not strings. This is probably something that can only be answered either by looking into the memory management white paper or by getting an answer from someone who played around enough with this (and JP qualifies for that).

[Travis_M.]

Good afternoon,

Well, this certainly is an interesting situation.  In the example “Unflatten string returns data from previous iterations”, the second iteration of the for loop unflattens a string as an array of strings type, this is obviously a type mismatch so if any data is returned I wouldn’t expect it to be valid.  What is even more interesting, is that if you don’t use the auto indexing, but rather explicitly index the array there is no error, but the data returned is like it was in 7.x.  I tried to use the flatten function’s “convert 7.x data function with no luck in either case.  I filed a bug report on this issue (number 3X0CBC3A), but it seems to me the only workaround for now is going to be just making sure the types match.  I know this is going to be inconvenient for you, and for that I apologize.

Incidentally, in many cases I wouldn’t necessarily expect an error to be generated if the types don’t match.  This is because the flatten to string function takes your data and converts it to a string which is nothing more than a byte[ ] of data with some size information.  When you “unflatten” the function takes the string it is given, and attempts to reconstruct the data in the format that is specified by the “type” input.  If it can reconstruct the data from type, regardless of the data returned I wouldn’t expect it to generate an error.  Sometimes, however, an error can be detected – if you flatten a double-precision number and unflatten to a single precision number LabVIEW can detect that the incoming data represents something much larger than a single precision number.  I suppose that LabVIEW 7 did a better job checking the size of the sting before deciding whether or not to generate an error.

Again, I apologize for the problems this may cause.  Please let me know if there is anything else I can help with.