LabVIEW type descriptors

[mike5]

We're working on some data serialization, and as a result I need to be able to parse the type definition data.

I have most of it figured out, but I'm getting a strange type after composing a very large cluster = 15 elements:

Namely - the type descriptor starts with:

00 67

00 F1 What the hell is type descriptor F1 ???? I can't find it anywhere

00 00 00 00

00 00 00 02

Next follow the name of the parent library and the name of the type def being serialized.

2 elements, I know. But I'd still like to know what "00 F1" stand for. Maybe someone with the ability to look at source (cough, cough)

Thanks in advance, Mike

[mike5]

Digging a bit further, the real problem for me comes later on:

So, the last type descriptor is as follows:

• two strings identifying the library that owns the type def (alright, I guess);
  
• the standard part of the type descriptor, listing the types of all the elements of the cluster;
  
• the name of the actual control/constant (comes from label).
  

is there a way to anonymize this type descriptor? Because now people (and that includes me), drag the type def onto the front panel and give it a name, since it's a parameter. But this means that the serializations differ because of the different parameter name - the third bullet point up there.

And since I don't know the full meaning of the data serialization (F1 up there), I don't analyze the serialization deeply enough and they look to be of different type, and some stuff fails because of it.

Or, can I at least get a nice description of how F1 type descriptor is composed so that I parse it properly, ignoring the stuff that is not important. Also, can I get a list of all the hidden Type descriptors like F1. I only know of the ones listed in http://zone.ni.com/reference/en-XX/help/371361G-01/lvconcepts/type_descriptors/

Thanks again, Mike

[crelf]

Have you looked at the OpenG type descriptor VIs? You might find something useful in there...

[mike5]

Unfortunately not, because OpenG uses "Variant to flattened string" and I am using "Flatten to string". I need the latter for its "define endianness" capability. And I think "Flatten to string" works a bit differently.

Br, Mike

[todd]

Mike, I think crelf means the type descriptor VIs (like Get TDEnum from Data), not the string ones. However, it looks like 1F is not specified.

[mike5]

Mike, I think crelf means the type descriptor VIs (like Get TDEnum from Data), not the string ones. However, it looks like 1F is not specified.

Yes, I know and I did. I found out that all OpenG type descriptor functions are centered around "Variant to flattened string" function.

I just wanted to point out that it seems like "Variant to flattened string" and "Flatten to string" are producing a little bit different header representation.

Br, Mike

[The J]

Would any of the VIs in \vi.lib\Utility\VariantDataType\VariantType.lvlib help you? You should at least be able to use the GetTypeInfo VI to see what your mystery F1 is.

[Aristos Queue]

Just FYI, the old "array of int16" type descriptors are all pretty much deprecated as far as LV R&D are concerned. There are many types that those arrays cannot accurately reflect, which is why we use the Variant library that "TheJ" mentioned.

[mike5]

Thanks TheJ, and AQ. I'll take a look at this.

Actually, it didn't help. The function knows how to look at inside the F1 type to determine that it contains a cluster. We have in the mean-time deduced that F1 stands for "type definition" or something similar.

So, if our cluster is in the type-def control, then it has F1, if we just copy it out and onto the block diagram as a constant, the F1 goes away, leaving only the cluster. There are still a few unknowns, but we'll hopefully figure them out sooner or later.

Br, Mike