[Bug] Unflatten From String Remainder

[Darin.K]

Wow, you NI guys really got me this time.  When Unflatten from String fails the 'rest of the binary string' output contains some random value from a previous execution.  What a major PITA that was to sort out, random old values being recycled intermittently.  Easy to reproduce in LV12 SP1

Start with a very simple VI:

Input a long enough string to get an I32 out (strings are set to hex display)

Nice and happy.  Now empty the input string are run again.

Say what?  Given the dearth of documentation on the expected output, it is fair to ask what it should be.  Error out and the value (default of 0) are both fine, but what about the remainder string?

Input string unchanged?  I say yes with a capital 'yes'.

Empty string? I could at least entertain an argument for returning the default value of the string type.  A weak argument, nonetheless.

Whatever the value of the remainder happened to be last time there was a successful conversion?  No way.

And no amount of Always Copy is going to help in this case.

[rolfk]

Seems like a slip up to me. I'm pretty sure that worked in earlier versions of LabVIEW as expected.

Aahh, no! There wasn't any remainder string there in 7.1!

And in 8.2.1 it shows the same behaviour.

Now, I understand that one should not do anything with returned data when an error is returned. But it would be consistent with many other LabVIEW functions to either return an empty string or more likely the original input string, although that could mean less optimization as the input string may have to be copied if it gets branched to any other function. But trying to optimize the error case should probably not be a high priority anyways. The compiler still could decide to not create any string at all, when the terminal is not wired.

[Darin.K]

Thanks for the check in previous versions!

This really has me in a pickle at the moment.  I use UFS to parse a firehose of incoming data with the goal of processing in real time (I mean fast, not deterministic).  The beauty/curse of large data sets is that even the highly improbable becomes likely.  Right now my code is fast enough, but buggy at about the 1 ppm level thanks to this.  Putting an extra error check (which is no error 99.9999% of the time) and/or branching the string wire just kills the performance (enough to move from just fast enough to too slow).  Attempts to recreate the Unflatten function in G are just slow.  Looks like this part of the code has to stay in C++ for the moment.

[PiDi]

Just a though: Request Deallocation function fixes this (at least in LV 2013). But this may also hit the performance.

[Yamaeda]

How much slower would it be to use String subset or Split string?

/Y

[Intaris]

I personally would have used "scan string for tokens" for this. I always found itvery fast and reliable.

[nathand]

Do you have the option of using Type Cast instead?

[Darin.K]

Any form of de-serialization by hand using string subset is going to be slower, and it is binary data so scan string for tokens is not going to help here (but I agree is it under-utilized in general).

Type Cast is one of my old favorites, but in this case Type Cast Man's kryptonite is a combination of 2D arrays and endian-swapping.

[Yamaeda]

Typecast to U64 and Split number should work with the caveat the 2nd is 0 when empty. Ought to be fast enough

/Y