Jump to content

Variant data advice sought


Recommended Posts

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.

Link to comment

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

Link to comment

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.

Link to comment

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

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)

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.

Link to comment

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

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

Dictionary_Update_(poly).png

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

Dictionary_Get_Value.png

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

Link to comment

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

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.

Link to comment

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.

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.