OpenG LabView Datatype Palette Documentation & Examples

[Zygle]

Hi everyone,

 

I'm looking for OpenG LabVIEW Data Palette documentation and/or example files. Especially I'm interested in methods for converting variant to data when data type is not known at design time. I already searched google and forums (including old openg.org) forum but most of the promising links are dead or not available. I found a very useful document about the building blocks and theoretical backgroung (http://openg.org/docs/LabVIEW%20Data%20-%201%20of%202.pdf) but the second part of the document about the Data Manipulation Design Patterns is missing. I'm beginning to understand but still missing the big picture which is why I would like to see these tools in action.

 

Any help would be greatly appreciated.

[hooovahh]

For the data to be usable you have to know what it is at some point.  Sure you can say you have a variant but if I'm going to get an average of a variant I need to know how to interpret the data.  Should this be a string, that is then transformed into a numeric?  Or is it a boolean and should be treated as a bit? Or is this an enum which corresponds to some value?

 

If you don't know what the data type is just yet, but you know that in two places the data type is the same, I highly recommend a type def.  Using the OpenG Write Key (Variant) and Read Key (Variant) under the Variant Configuration palette I can write and read any thing to a file.  Quite nice but at some point I'm going to need to turn that variant into a usable data type.  Variants are great for a transport layer where we don't really care what the data is we just send it and then the place that receives it needs to convert the variant back to something usable.  The Write and Read Key can be thought of as the transport layer where we send some data as a variant to a file, then we receive it back when we read it.  For it to work properly ideally the write and read have the same data type.  If these are both linked to the same type def, then that means updating the one type def will update both the write and the read to use the new data type.  We may not know that data at design time, but we know what ever we write, we are also going to want to read and the data had better be the same.

 

I've seen variants used in Queues, User Events, TCPIP, File I/O, FIFO, and several other transport layers.  These all work great because they don't care what they are given they just send the bytes and who ever gets the bytes is responsible for getting usable data out of it.  If you aren't dealing with a transport layer, and instead are just passing data around a VI but don't know what it is yet, there isn't really a need to use a variant, just stick with the type def and update it when needed.

[drjdpowell]

You could look at some of the packages in the Code Repository that use the OpenG Data tools (Variant Probe for example).

I’d say there are two main uses:

1) Make reusable tools to handle an arbitrary cluster.  The OpenG Variant Configuration File package is an example.  Here the User of the tool at some point needs to convert the variant back to a known type.

2) Make a display that converts an arbitrary type into a string.  The VariantProbe above is an example.  

 

— James

[Zygle]

Thank you both for the explanation. I'm already using variant mainly in queues, in very similar way to what hooovahh suggested. I'm researching posibilities to make my code more reusable (i.e. more data independent) and was curious what OpenG has to offer in that area. I will definitely check Variant Probe and the OpenG Variant Configuration Package.