LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Binary file compatibility

Solved!
Go to solution

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.

2016-10-31 14_14_49-Dokument1 - Word.png

Thanks in advance for any advice. CR

0 Kudos
Message 1 of 9
(4,769 Views)

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!

Best regards,
GerdW


using LV2016/2019/2021 on Win10/11+cRIO, TestStand2016/2019
0 Kudos
Message 2 of 9
(4,753 Views)

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.

0 Kudos
Message 3 of 9
(4,749 Views)

@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?

0 Kudos
Message 4 of 9
(4,732 Views)

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.Smiley Surprised

 

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.Smiley Frustrated

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!

0 Kudos
Message 5 of 9
(4,700 Views)

@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

G# - Award winning reference based OOP for LV, for free! - Qestit VIPM GitHub

Qestit Systems
Certified-LabVIEW-Developer
0 Kudos
Message 6 of 9
(4,686 Views)

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.


GCentral
There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines
"Not that we are sufficient in ourselves to claim anything as coming from us, but our sufficiency is from God" - 2 Corinthians 3:5
Message 7 of 9
(4,679 Views)
Solution
Accepted by CtheR

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.

Message 8 of 9
(4,664 Views)

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.

Message 9 of 9
(4,646 Views)