10-31-2016 09:14 AM
Short Story:
Saved binary files in LV 2015 cannot be read by LV 2012 (error code 122). Is there a way to save it from 2015 "with compatibility" so I can read it with 2012? File contains String and Variant data if that matters.
Long Story:
There is a Labview 2012 compiled app running on ~50 desktops in our company. It displays the status of a machine by reading a binary file from the network that the machine writes.
Now I rewrite the software for this certain machine with LV 2015. When I save the status binary in LV 2015 it is not readable by LV 2012, which throws a compatibility exception, code 122. Is there any workaround / compatibility mode so that I do not need to update all installations of the LV 2012 desktop programm? File contains String and Variant data if that matters.
Forcing our engineers to install LV 2015 runtime over 2012 will be painful. Everyone will go: Bah, f**k Labview.
Thanks in advance for any advice. CR
Solved! Go to Solution.
10-31-2016 09:40 AM
Hi CtheR,
File contains String and Variant data if that matters.
Your file contains a cluster with several other datatypes inside. The information on the actual datatypes is stored within the file together with an information of the LV version used to generate the file. Additionally the way how this information is stored can change with every LabVIEW version as it mainly contains LV internal information. Your kind of "binary file" is merely just a "datalog file"…
Solutions:
- Use LV2012 to generate those files.
- Don't use "datalog files" - use your own data format when writing/reading those data!
10-31-2016 09:47 AM
It really isn't that hard to install LV 2015 runtime to go side by side with LV 2012 runtime. Just create the installer for that and your newly compiled app and have them run it.
50 machines is a lot, but if you have a good IT dept, then can arrange for that to install automatically on all 50 machines without the users ever needing to worry about it.
Why didn't you just write the binary file using a LV 2012 version of the VI's?
Why it's not compatible? I don't know. It is kind of hard to trouble shoot from a screenshot from a small section of code. We can't even tell what that datatype is other than it is some sort of cluster. You say it is a string and a variant. What kind of data is going to the variant?
Attach some actual VI's that demonstrate the problem.
10-31-2016 11:06 AM
@CtheR wrote:Now I rewrite the software for this certain machine with LV 2015
What is your definition of "rewrite". Did you load the original code in LabVIEW 2015 or did you change anything?
10-31-2016 06:52 PM
Thanks for your answeres.
Now I know that it is no specific issue but a general ~incompatibility~. That is important for me to know. Actually in all the years of Labview part-time programming (since 7.1) I never encountered this.
To answer your questions:
What kind of data is going to the variant?
Clusters of "stuff". It is a keyword/OP-Code with the variant containing data type dependent on the OP-Code. So I can update new entries and wire them though the programm as cluster of string and variant only unpacking the variant where I need to work on the data.
What is your definition of "rewrite"? Why didn't you just write the binary file using a LV 2012 version of the VI's?
It is one of those big and grown over time projects. Contains > 200 DIO and >30 AI in use for Pneumatics, Servos, Measurements, Cameras, Network and Serial Communication, Climatic Controls, Programmable by its own (simple) meta-programming language, time-critical code parts running on external RT, running 24/365. Actually not one (like it sounded in my post) but also >40 installations of it.
It needs functional updates of ~very various~ kinds not fitting into the structure of the actual labview code. So I need to rewrite critical parts, some of them > 10 years. I hoped for a reuse quote of old code of ~50 %. With the binary incompatibility it kind of drops to 48.5 % - you know what I mean.
I hoped to save some of my time and avoid updating the desktop monitor software / getting into it again/ testing it / discussing it.
Also the guys here hate it to install new software on their precious sleeky PCs just to restore functionality that already is there. They hate labview already like everyone uses but hates MS Windows (lets not discuss this, I know why I love LV).
I use LV 2015 instead of 2012 now cause I wanted to. Started with it on this project and I'm already 60% done.
Anyways, feels good to do more LV again these days.
Thanks!
11-01-2016 02:56 AM
@CtheR wrote:Is there any workaround / compatibility mode so that I do not need to update all installations of the LV 2012 desktop programm?
No, since code made in Lv2015 will need the 2015 Runtime engine you're basically screwed. You'll need to install LV2012 and downsave the code to continure the work there. I agree it is strange the binary format has changed though.
/Y
11-01-2016 08:12 AM
CtheR wrote: File contains String and Variant data if that matters.
Your problem is the Variant data. The format of the Variant can (and does) change between versions. What you probably should do is extract the data that is in the variant and store it as a cluster or name-data pairs.
11-01-2016 12:26 PM
If you are using enums in variant and added new entries (even within single version), it can also affect conversion.
That is why I prefer flatten to string, not variant.
11-02-2016 04:20 AM - edited 11-02-2016 04:26 AM
Thanks everyone. It is solved by using flattened string.
Now I save the old *.bin file with the variant from 2012 installations
and a new *.bi2 file with flattened string from 2015 installations.
My collegues can now remain using 2012 RTE. I only change the 2012 desktop app exe file which is on the network anyways, so they woun't even recognize.
If it finds a *.bi2 file it prefers it over a *.bin file with the same name. Then loads the flattened string,changes it to variant (2012 style) internally, and then works on the data as usual.
Thanks everyone, you all have been helpful.
I'll flag Alexanders answer as Solution because he was the first on that brought in flattened strings.