LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Did the unflatten from string vi change from V6 to V8?

I wrote an app in LV6 that flattened a cluster of two 2d arrays and a waveform to a string, then wrote the string to a file.

Then I would retreive the string from the file and unflatten it back to two 2d arrays and a waveform.

 

I've written a new app in LV2010 using the same file read and unflatten code, but get an error 116 when trying to unflatten the string from files created with the LV6 code.

0 Kudos
Message 1 of 21
(3,186 Views)

That would be why there is a Right-Click option to "Convert 7.0 Data"

 

Or essentially, Yes, the data types have evolved in the last few decades. 


"Should be" isn't "Is" -Jay
0 Kudos
Message 2 of 21
(3,178 Views)

@JÞB wrote:

That would be why there is a Right-Click option to "Convert 7.0 Data"


Interesting enough, the Flatten has the "Convert 7.x Data" option while the Unflatten has "Convert 4.x Data".  Something seems really off here.


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
0 Kudos
Message 3 of 21
(3,135 Views)

@crossrulz wrote:

@JÞB wrote:

That would be why there is a Right-Click option to "Convert 7.0 Data"


Interesting enough, the Flatten has the "Convert 7.x Data" option while the Unflatten has "Convert 4.x Data".  Something seems really off here.


It just seems that way Tim,  I could tell you to go read the help files Smiley Wink


"Should be" isn't "Is" -Jay
0 Kudos
Message 4 of 21
(3,112 Views)

Not really.

 

The Flatten change between 7.x and 8.0 is mainly related to the output of the type descriptor. The format of the typedescriptor has been changed in 8.0 to internally use 32 Bit offsets rather than 16 bit ones and a few other changes to make them more effective. As a result the type descriptor was considered private data and hidden from the Flatten node. Even if it would return some kind of type descriptor it would be very different between 7.x and 8.0. The binary format should not have changed in between the two version, except that there are new datatypes that came in 8.0.

 

The change between 4.x and 5.0 was a data change in the binary flatten format. Booleans were changed from 16 bit voor scalar booleans to 8 bit and for boolean arrays from packed format (an array of booleans was really always a multiple of 16 bits long, with the booleans packed) to one byte per boolean.

Rolf Kalbermatter
My Blog
Message 5 of 21
(3,110 Views)
Thank Jeff. I'll try it.
0 Kudos
Message 6 of 21
(3,086 Views)

Thanks Rolf-

 

I didn't have all of those help files handy and was not 100% certain of the details- I knew it made sense and, where to look it up!  Just missing the reference material!


"Should be" isn't "Is" -Jay
0 Kudos
Message 7 of 21
(3,080 Views)

I tried the "Convert 4.x Data" option, and now I get an error 74.

 

I've gone back to the old XP development machine and installed my original LV 6.1 app. The executable still reads the files fine. However, when I bring up the source in LV 8.6.1 (I don't have LV 6.1 on this machine anymore, just the run-time library), I get the same results -- error 116 without the "Convert 4.x Data", error 74 with "Convert 4.x Data".

 

It still appears to be related to a change that happend from LV6 ro LV8.

 

Any thoughts?

0 Kudos
Message 8 of 21
(3,030 Views)

Can you post the LabVIEW 6.1 code of the relevant routine? I'm not really aware of a data change between 7 and 8 but it may be something subtle.

Rolf Kalbermatter
My Blog
0 Kudos
Message 9 of 21
(3,009 Views)

If I were to make a wild guess here I would imagine that you are using the 'Write Characters to File.vi' in LV6 which I seem to remember defaults to False for the 'Convert EOL' option.  In LV8+ you have the Write To/Read From Text File functions which default to True for that option (now a right-click configuration).  This causes many a subtle error in the serialization/deserialization process.

0 Kudos
Message 10 of 21
(3,004 Views)