Conditionally typedefed clusters as indicators

[ijustlovemath]

I'm writing a driver for a serial device, and one of the functions is parsing the response of the device to a command. The device can respond with a sample result (cluster type 1), a status string (cluster type 2), or version information (cluster types 3-6). I've got a typedefed enum as my control going into this VI, so there's a case statement that will parse the appropriate information and send it out in a cluster for use. The problem is that I've got 6 different clusters that may come out depending on what command is being parsed. Is it possible to have one indicator that takes on multiple different data types? If not, is there some other way to handle this elegantly?

Code is in the attached zip file, as well as documentation on the serial protocol in question. Section 9 describes the protocol.

[GerdW · Accepted solution]

Hi math,

Is it possible to have one indicator that takes on multiple different data types?

That one is called "variant"…

It will take any datatype you like to stuff into, but that doesn't help you immediatly. You still need to know the datatype you stuffed into the variant.

So one often used approach is to create a cluster of an enum and a variant. The  enum describes the datatype stored in the variant. When reading the cluster you first read the enum and use it to select one case in a case structure. That case correctly reads the data from the variant…

Another approach is to create a cluster with an enum (same meaning as before) and several "standard" datatype indicators. You store your information in those indicators. From your description it seems you need to store numbers ("sample result") and several strings ("status", "version information")…

[ijustlovemath]

Weirdly enough, I did think to do just that! I always heard that variants are much slower than using normal data types, and that needing to use one was indicative of bigger problems in your code. Would you agree with that? Would it instead be better practice to have each cluster-specific group of commands have their own VI?

[mikeporter]

Variants certainly work. Other options would include creating a polymorphic VI, or use object oriented and handle the variability via dynamic dispatch.

Mike...

[ijustlovemath]

Mike, do you have any references for this kind of OOP in LV?

[mikeporter · Accepted solution]

I have written quite a bit about OOP and have made 2 presentations at NIWeeks on the topic. Start here and read the next couple posts:

http://www.notatamelion.com/2015/04/06/objectifying-labview/

On my website you can also find the papers I presented.

Mike...

[nathand]

Not sure where you heard that about variants, but they're neither slow nor inefficient, although of course there's a small performance penalty versus a defined data type. In most cases when you convert to a variant no data copy is necessary, it just adds a new reference saying "this is now a variant". When you convert back from a variant there's a check that it's the right data type, and if it is, no data copy necessary, LabVIEW just redefines the data type from variant back to the underlying type.

Flattening to a string is much more inefficient.