Variant data advice sought

[Graeme]

Hi All,

I have a top level VI designed for other developers in my organization to expand as necessary. Simply, it is a state machine, each state of which is intended to hold code that will run a test and return a single test result. The data types of the results are only ever going to be Boolean, Numeric or String. The results need to be checked for pass or fail, displayed, then built into a result string array for writing to file. To this end I've written near identical 'result handler' VIs to do this for each data type (which I could make into one polymorphic VI). A developer then places the appropriate result handler VI in each state machine case as required.

It struck me that I might be able to do all the result handling with a single result handler VI in the following manner. Each result would be converted to Variant data and this wired to an output tunnel on the state machine case structure. This in turn would be wired to a single modified result handler VI outside the case structure. The modification would be that the result handler VI would accept Variant data as its input and would convert back to the correct data type for processing by a successive trial and error method. In this way, fellow developers need not concern themselves about the result handler VIs at all. In essence, I'm trying to get different data types through one tunnel.

My question is, what do others think of the proposed technique? Is it accepted programming practice and is it sound? I should add, my data sets are very small in the greater scheme of things and execution time is not critical. Thanks in anticipation.

Regards, Graeme.

[LAVA 1.0 Content]

Hi Graeme,

what you want can certainly be done, but I have 2 more sophisticated mechanisms:

Stamping, where you store the data in a cluster consisting of a string (stamp) that says the data type and a variant which contains the data.

Even better would be a LVOOP approach, you define a LabVIEW class 'Graeme's Data' with a dynamic dispatch VI 'Data handler', each developer creates a child class with the appropriate 'Data handler' VI to handle the data.

Good luck,

Ton

[crelf]

QUOTE (Graeme @ Sep 27 2008, 05:12 AM)

The modification would be that the result handler VI would accept Variant data as its input and would convert back to the correct data type for processing by a successive trial and error method.

You might want to check out the "lvdata" OpenG package - there's a few tools in there that will help you determine and work with vairnat-based datatypes.

http://lavag.org/old_files/monthly_09_2008/post-181-1222534330.png' target="_blank">

[Graeme]

Ton and Crelf,

Thank you both for your replies. I feel heartened that neither of you have replied in the negative. Without wishing to extend this, probably dull to most, posting into an endless one I would like to take the aspects you both mention a little further.

Ton, your two suggestions intrigue me. Alas I'm not a programmer by birth, but an escapee from the world of RF test engineering. Thus, you would have to spell out your stamping suggestion a little more for me, for the penny to drop. Regards, OOP, well, I've seen it referred to a lot, but to be honest I haven't a clue about it. I certainly don't expect you to solve my problems for me, but if you knew of a link to an "LVOOP for dummies" or similar, I would be happy to learn from there.

Crelf, like OOP, I've seen references to OpenG a lot. Similarly, I don't really understand it, never having pursued it, though I probably should now, but I have a (slightly off topic) question. I summise that to get OpenG VIs you install VIPM which downloads them from the Internet. At work, where I do most of my LV coding, there is absolutley no way our PCs can ever be connected to the Internet. However, I run LV at home on a PC which is connected to the Internet. My question is, can I use OpenG VIs at my work place some how?

To maitain relevance I should add that my original post in this topic is the last niggle in a project that I've been working on for two years. It would seem my solution would work but is a little clunky, and I'm the first to admit that. A slick solution would be excellent, and if finding such enhanced my LabVIEW skills as well by methods new to me then that would be a bonus.

Regards, Graeme.

[crelf]

QUOTE (Graeme @ Sep 27 2008, 05:43 PM)

Without wishing to extend this, probably dull to most, posting into an endless one I would like to take the aspects you both mention a little further.

Are you kidding me? This is a great topic! It's technical, it's talking about a pattern that's a little out-of-the-box, I like it

QUOTE (Graeme @ Sep 27 2008, 05:43 PM)

...if you knew of a link to an "LVOOP for dummies" or similar, I would be happy to learn from there.

OOP is a pretty important paradigm - have a look at this to get an idea. Whenever I teach an OO class, I show a standard File I/O VI or DAQmx, and ask who has used them - invariably everyone's used at least one of them, and I tell them: "you're already doing OO"...

QUOTE (Graeme @ Sep 27 2008, 05:43 PM)

Crelf, like OOP, I've seen references to OpenG a lot. ...never having pursued it, though I probably should now...

You should indeed. Think of it as LabVIEW with extras - it'll significantly enlarge your palettes, much like other things advertised on the internet...

QUOTE (Graeme @ Sep 27 2008, 05:43 PM)

...can I use OpenG VIs at my work place some how?

You sure can! Here's a FAQ entry on how to do just that.

Anyway, back to the original question: you might want to consider putting together a current value table (CVT) that's based on the attributes of a variant (with polymorphic write and read methods) - you can have a theoretically infinite number of variants (the attirbutes are vairants themselves) that you can name, rather than stuffing everything into one variant. More info here.

[LAVA 1.0 Content]

QUOTE (crelf @ Sep 28 2008, 03:38 AM)

Are you kidding me? This is a great topic! It's technical, it's talking about a pattern that's a little out-of-the-box, I like it

Ditto!

QUOTE (Graeme @ Sep 27 2008, 11:43 PM)

Crelf, like OOP, I've seen references to OpenG a lot. Similarly, I don't really understand it,

Well OpenG is a toolbox, it comes with a lot of little programming snippets that will enhance your life (at least your programming life).

On topic it contains a dictionary toolbox. If you have installed OpenG (how to) you will have a help topic on the dictionary toolbox, but basically it is a toolset of data that is addressed by a key, this key can be anything (truely) but I suggest a string to get started. Every piece of data to store is saved with a look-up key. Using this function

To retrieve the info (stored in value) use this function

QUOTE

A slick solution would be excellent, and if finding such enhanced my LabVIEW skills as well by methods new to me then that would be a bonus.

A slick example always gets you further in the long run.

Ton

[crelf]

QUOTE (Ton @ Sep 28 2008, 04:33 AM)

On topic it contains a http://wiki.openg.org/Oglib_dictionary' rel='nofollow' target="_blank">dictionary toolbox.

Great point Ton - the OpenG Dictionary is an implementation of a Current Value Table (CVT) as discussed above. Don't be confused by it's title of "dictionary" - it's not for spellchecking It's a dictionary in the sense that you can define terms (name/value pairs) and then retrieve (or re-defined) those terms and their definitions (ie: values) later.

[jzoller]

If you prefer a built in, by value (rather than by reference) dictionary, variant attributes work wonderfully well.

Dark side: http://forums.ni.com/ni/board/message?boar...ssage.id=209272

Joe Z.

[crelf]

QUOTE (jzoller @ Sep 28 2008, 03:09 PM)

...variant attributes work wonderfully well.

http://forums.lavag.org/-t11380.html&view=findpost&p=48336#entry48336' target="_blank">Great minds think alike

[Graeme]

As ever, I'm indebted to all who have replied. Thank you for taking the time and going to the bother of doing so. You have given me much to think about and pursue. Both LVOOP and OpenG sound exciting and powerful. I suspect you have pointed me down paths well beyond the scope of my initial posting. Although time hasn't allowed me to do so yet, I shall follow up your suggested avenues with vigour as soon as I can. I wonder if I'm about to embark on that journey where a LabVIEW boy becomes a LabVIEW man... :worship: Thanks again.

Graeme.

[crelf]

QUOTE (Graeme @ Sep 29 2008, 03:06 PM)

I shall follow up your suggested avenues with vigour as soon as I can.

Let us know how it works out for you Gov'ner!