Error 122 ( Version Incompatibility) when using "flatten to string" and "unflatten from string"

[SBach]

Hi everybody,

I encountered a problem with different LabVIEW ( 2016 and 2017) versions when using "flatten to string" and "unflatten form string".

We program an application that utilizes a client / server approach. We deploy the Server together with some hardware , pre-installed and give the Customer his client as an installer or as VIs to include in his own LabVIEW code.

We use the VIs mentioned above to serialize different kind of data in the client application, send it over a TCP connection to the server application and de-serialize it again.

This works as long as both server and client are of the same LabVIEW Version. If one of our Customers need his client in 2017 it does no longer work as our server is LabVIEW 2016. In that Case Error 122 occurs if we try to de-serialze the data.

Does anyone knows how i can work around this? My  current solution is to install LabVIEW 2017 to another machine and recompile our server.

If found this topic: https://forums.ni.com/t5/LabVIEW/Why-is-a-flattened-variant-different-in-LabVIEW-2012-and-LabVIEW/m-...

I tested the suggested solution with the <vilib>\Utility\VariantFlattenExp.vi. but I fail when I try to unflatten it with the normal "unflatten from String" VI and another "unflatten" VI is not mentioned in teh topic. Do somebody know a VI to unflatten data flattened with  <vilib>\Utility\VariantFlattenExp.vi?

I did some more searches and found two other topics ( none of them works for me):

https://forums.ni.com/t5/LabVIEW/LV-2012-Flatten-To-String-Unflatten-From-String-problems/td-p/24028...

https://forums.ni.com/t5/LabVIEW/Unflatten-variant-from-string-got-error-122/m-p/3174711

These two are about writing binary data to files,so the suggested solution with changing the EOL handling does work for me.

Regards

Bachi

[Bob_Schor]

This is an excellent question, one that I would call NI Support and ask about.  I couldn't find any mention of a change in handling Variants in the Release Notes, but might not have looked in the right places ...

Bob Schor

[crossrulz]

---

@Bob_Schor wrote:

I couldn't find any mention of a change in handling Variants in the Release Notes, but might not have looked in the right places ...

---

Nor will you.  That is because variants change for every release (LabVIEW version is included in the flattened data).  You can unflatten a variant from an older version, but not a newer version.  So the solution is to update the server to 2017 and it will still work for both clients.

[rolfk]

Another solution is to not use any Variants, or Waveform data in the flattened stream but instead convert it to and from the standard basic datatypes (Integers, Floats, Boolean, String) and Arrays and Clusters of these.

[SBach · Accepted solution]

Hi everybody,

Thanks for your quick replies.

Unfortunately I can' t keep variant elements out of my TCP transfer as I transfer clusters with Command Enum and Parameter Variant.

BUT:

I did some more tests with the approach suggested by gregstoll in this topic:

https://forums.ni.com/t5/LabVIEW/Why-is-a-flattened-variant-different-in-LabVIEW-2012-and-LabVIEW/m-...

and it did solve my problem but I made a mistake when testing it yesterday.

I did not take into account that the <vilib>\Utility\VariantFlattenExp.vi. is a VI that serializes VARIANT and therefore it autocasts any input to a variant. So I cannot simply unflatten to my data type directly, but have to unflatten to variant and then use the "Variant to data" VI to cast to my data type.  See the picture attached to this post.

So my problem seems to be solved . Thanks to every body for the Help.

Regards,

Bachi

[ibberger]

Sorry for digging out this old thread, but I have some information, someone might find usefull.

I experienced the same error, in a similar scenario as SBach initially described.

I also use "flatten variant to string" and "unflatten from string" to send misc. data from and to a cRIO target, including the allready mentioned "enum and parameters" wrapped in a cluster data.

My structure looks like this:

In the Windows EXE the misc. data are first converted into a variant, which again is flattened to string before beeing sent via TCP/IP.

on the RT, the output of  the TCP Read primitive is directly connected to a sub-VI which parses the data.

I experienced the following:

when testing my code in the IDE (running the RT VI from the IDE) everything worked fine. After a while I decided the RT code is stable and compled it. The cRIO was running from the compiled exe from now on. Also everything was working fine. Finally I decided that the Windows exe is ready for release and complied it. This was when the trouble started.

When running the exe I got error 122 on allmost any cluster, converted to variant, then flattened to string the cRIO tried to reassemble to a variant from "type & data" in the received bit stream. This was pretty strange, because all worked fine in the IDE. Even more strange: the compiled exe was running fine on a laptop, which had no LabVIEW IDE, but just the corresponding LabVIEW Runtime Engine installed.

Overview:

Windows VI running in IDE + RT-VI running in IDE = working

Windows VI running in IDE + compiled RT-EXE = working

Windows EXE + compiled RT-EXE = not working, error 122

Windows EXE + RT-VI running in IDE = not working, error 122

Windows EXE on other machine = working with either running the RT VI in the IDE or as RT-EXE

Maybe I should also mention: this code shown above is allmost prehistoric, I'm using this procedure since the stone age (LabVIEW 5/6) and it never failed. What's also interesting: I use the same code to transmitt data from the cRIO to the Windows Software, without problems ...

What I tried to solve it:

• I removed all "flattend to string" and "unflatten from string" primitives and reinserted them - no effect.
• I tested it with plain datatypes (e.g. i32 converted to variant, then flattened to string ...): works, but clusters don't
• I formated the cRIO and reinstalled LabVIEW + my application, with no effect.
• A "repair installation" of LabVIEW on my development PC did not help - still the same behaviour:
• I removed all "flattend to string" and "unflatten from string" primitives and reinserted them - no effect.

I asume some file in my NI software is corrupted and the application builder grabs an instance of the "flatten to string" primitive, which is not the one it shoud use. But I don't see any chance to figure out where this "illegal" file is coming from.

So my next steps will be: remove all NI software from my PC and reinstall it. If that does not work: format c:/ and reinstall Windows. If that does not work ... take the "electronics repair hammer" and smash that whole crap 😁 - this may not be an appropriate solution either, but at least it's some stress relief 😉

If anyone had a hint like "clear your Application Builder cache directory at C:\ni\whatever\blah" and try again, I'd really appreciate it.

Thanks,

cb

[Bob_Schor]

Having done dozens of "Remove all NI Software and reinstall one or more versions of LabVIEW" in the past 4 years, and only twice having to "Reformat the C: Drive, reinstall Windows 10, etc." (due to my own stupidity of messing with the Windows Registry as part of the cleanout), as long as you do the "Remove all NI Software" step safely, you should be OK.

If you search the Web, you can find NI White Papers on how to do a safe removal of all NI Software.  I wrote a note in this Forum several years ago, but I've been unable to find it (searches in the Forum are not so robust), but my method and NI's are essentially the same.  The Important Principle is do not delete files or folders until you have uninstalled everything NI-wise that you find in Control Panel's Programs and Features (including VIPM, VISA, IVI, etc.).

Note that this might be an excellent time to restrict your local LabVIEW installation(s) to the most recent 3-4 Versions (I think NI is committed to maintaining some level of compatibility for about this long).  If you really need older versions (which probably also require older Operating Systems), consider spinning up VMs.

Bob Schor

[ibberger]

Thanks for the Reply, Bob.

I'm currently removing all NI software, as nothing helped. Yes I remember there are some whitepapers around. ATM I'm letting the NI Package manager delete all the stuff. I will see what's heft after this process is finished ...

By the way: the Windows 10 installation is quite new, max. a year old, and I had only LV2015SP1 and LV2018SP1 installed. My gut feeling says: I should have removed all NI software before I started using the NI Package manager and installing LV2018 - but that's just a guess.

[ibberger]

BTW²

an possible Entry-Point for "Remove all NI Software" is here:

https://www.ni.com/de-de/support/documentation/supplemental/18/uninstall-or-repair-national-instrume...

[ibberger]

removing all NI software, deleting all folders in Programms and Programms(x86) named "National Instruments" and reinstalling the NI software afterwards did the job.

I asume there was something wrong with my local LabVIEW runtime engine, as the problem only existed on that particular machine.