mike5 Posted November 4, 2011 Report Share Posted November 4, 2011 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 Link to comment
mike5 Posted November 4, 2011 Author Report Share Posted November 4, 2011 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 Link to comment
crelf Posted November 4, 2011 Report Share Posted November 4, 2011 Have you looked at the OpenG type descriptor VIs? You might find something useful in there... Link to comment
mike5 Posted November 8, 2011 Author Report Share Posted November 8, 2011 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 Link to comment
todd Posted November 8, 2011 Report Share Posted November 8, 2011 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. Link to comment
mike5 Posted November 9, 2011 Author Report Share Posted November 9, 2011 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 Link to comment
The J Posted November 16, 2011 Report Share Posted November 16, 2011 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. 1 Link to comment
Aristos Queue Posted November 17, 2011 Report Share Posted November 17, 2011 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. Link to comment
mike5 Posted November 18, 2011 Author Report Share Posted November 18, 2011 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 Link to comment
Recommended Posts
Please sign in to comment
You will be able to leave a comment after signing in
Sign In Now