Unflatten From String on Class - Error 1527

[jgcode]

Howdy!

Warning! - This may be stupid question (please bare with me tho)

In a project, data (hierarchy of classes, which contain clusters) is saved to disk on the Real Time

The file is read back on desktop PC.

(This has worked fine for ages) What is now coming back is error 1527 on the unflatten from string primitive.

Error 1527 occurred at an unidentified locationPossible reason(s):LabVIEW:  Attempted to read flattened data of a LabVIEW class that is not currently loaded into LabVIEW.

As with the nature of Real Time, you need to save files before compiling down to the target.

Therefore my questions are:

1. Does the error relate to a class version mismatch (i.e. the Real Time has a newer version than the desktop PC)?
2. Could the class version have been incremented in the compiling down to the target (but was never saved as the file was never checked out and subsequently everything is now out of whack)?
3. Or could it be something else?

Cheers

-JG

[Jarrod S]

Howdy!

Warning! - This may be stupid question (please bare with me tho)

In a project, data (hierarchy of classes, which contain clusters) is saved to disk on the Real Time

The file is read back on desktop PC.

(This has worked fine for ages) What is now coming back is error 1527 on the unflatten from string primitive.

Error 1527 occurred at an unidentified locationPossible reason(s):LabVIEW:  Attempted to read flattened data of a LabVIEW class that is not currently loaded into LabVIEW.

As with the nature of Real Time, you need to save files before compiling down to the target.

Therefore my questions are:

1. Does the error relate to a class version mismatch (i.e. the Real Time has a newer version than the desktop PC)?
2. Could the class version have been incremented in the compiling down to the target (but was never saved as the file was never checked out and subsequently everything is now out of whack)?
3. Or could it be something else?

Cheers

-JG

I have seen this error happen before for classes that belonged to a LV library. They would fail to be unflattened with this error even though the class was indeed in memory. I believe this bug was fixed in LV2009.

[Aristos Queue]

Usually, this happens when you have a Child class being flattened on the RT system and on the host system, you unflatten it as a Parent class, without the child class actually being loaded on the host side.

[jgcode]

Thanks guys

I have seen this error happen before for classes that belonged to a LV library. They would fail to be unflattened with this error even though the class was indeed in memory. I believe this bug was fixed in LV2009.

Yes, the Classes are in a LabVIEW Project Library (for namespacing). But the Dev Env is 2009.SP1

Usually, this happens when you have a Child class being flattened on the RT system and on the host system, you unflatten it as a Parent class, without the child class actually being loaded on the host side.

I am not the author of the code (and not a work at the moment) but I am pretty sure the Class being read has two Classes as data members, one of which would be child class at runtime.

Is there any way to 'load it' - I mean the code its all there in src tree/project, and it was all working previously, so I am not sure why now it fails. I am also pretty sure those methods are called on the Real Time, and that has been working fine too.

Cheers

-JG

[Aristos Queue]

If it is listed in the project or is used by any open VI then it is already loaded.

It's not a version problem -- that's a separate error code. This error only occurs when the data was flattened with a class of name XYZ and when unflattening there is no class of name XYZ in memory. I don't know (or at least don't recall) the bug that Jarrod S mentioned. As far as I know, that's the only situation you should be getting this error.

Look at the actual flattened string... you should be able to see the name of the class embedded in the binary string. Look at the Class Hierarchy window. Is that class in memory?

[jgcode]

It's not a version problem -- that's a separate error code. This error only occurs when the data was flattened with a class of name XYZ and when unflattening there is no class of name XYZ in memory. I don't know (or at least don't recall) the bug that Jarrod S mentioned. As far as I know, that's the only situation you should be getting this error.

Look at the actual flattened string... you should be able to see the name of the class embedded in the binary string. Look at the Class Hierarchy window. Is that class in memory?

Ha! Turns out it was a bug. The class string is now compressed (the class names weren't even showing up, so this is how I stumbled on this), but the read methods weren't updated (and I didn't know about the change). So that explains it all.. and its ok, 'cause now my problem is sorted and I learned some stuff about error 1527

[Aristos Queue]

Ha! Turns out it was a bug.

A bug in *your* code, not mine, I take it. Yes?

[Daklu]

I've now run into this same problem using Labview 2009 sp1. Can anyone tell me why this code generates an error?

Error 1527.zip

[jgcode]

I've now run into this same problem using Labview 2009 sp1. Can anyone tell me why this code generates an error?

Hi Dave

I think this is a bug with XML and namespacing - try taking the Class out of the .lvlib then running the combinedReadWrite.vi again - do you get no error?

The workaround is to use binary strings (if that fits your requirements?):

Cheers

-JG

[Daklu]

I think this is a bug with XML and namespacing - try taking the Class out of the .lvlib then running the combinedReadWrite.vi again - do you get no error?

Yes, when not in the library it works fine. (It also works in 2010.) One of your earlier posts indicated you had it working in 9.0.1 even though it was in a project library... or did I misinterpret that?

I still don't trust auto mutation enough to commit to binary strings. At least with xml the data is readable and relatively easy to recover should anything bad happen. My solution is to transfer the relevant class fields to a cluster and flatten that to xml. Kind of pain, but safer than auto mutation.

[jgcode]

Yes, when not in the library it works fine. (It also works in 2010.) One of your earlier posts indicated you had it working in 9.0.1 even though it was in a project library... or did I misinterpret that?

I still don't trust auto mutation enough to commit to binary strings. At least with xml the data is readable and relatively easy to recover should anything bad happen. My solution is to transfer the relevant class fields to a cluster and flatten that to xml. Kind of pain, but safer than auto mutation.

Just for fun I just tried your code in 2011 and it seemed to work fine... ...upgrade time.