multiplexer in labview?

[prads]

Hello,

I am new to labview. I want a node which accepts different inputs and gives a single output maybe by placing all the properties/inputs defined adjacent to each other or in a similar fashion (--something like a multiplexer). Is there any VI that I can use? Does the bundle.vi do a similar thing?

Thanks,

prads

[jgcode]

Maybe try index array?

[Justin Goeres]

QUOTE (prads @ May 20 2008, 10:58 PM)

I am new to labview. I want a node which accepts different inputs and gives a single output maybe by placing all the properties/inputs defined adjacent to each other or in a similar fashion (--something like a multiplexer). Is there any VI that I can use? Does the bundle.vi do a similar thing?

Yes, what you're probably looking for is Bundle. Another (easier-to-read) option is Bundle By Name. There might be specific usage examples of each of them in the LabVIEW help, but I don't know for sure.

[Yair]

You might wish to go over some of these tutorials.

[gb119]

QUOTE (prads @ May 21 2008, 06:58 AM)

Hello,

I am new to labview. I want a node which accepts different inputs and gives a single output maybe by placing all the properties/inputs defined adjacent to each other or in a similar fashion (--something like a multiplexer). Is there any VI that I can use? Does the bundle.vi do a similar thing?

Thanks,

prads

QUOTE (jgcode @ May 21 2008, 07:42 AM)

Maybe try index array?

Sounds more like Interleave 1D Arrays to me.

If the inputs to be multiplexed are all of the same type then probably want to build them into a 1D array. If each input is a single scalar number then the node 'build array' will do this. If the inputs are each arrays, but you want the output to take the first element from each input and then the second and so forth, then 'interleave 1D arrays' is what you want.

If the inputs to be multiplexed are all different types. the the bundle/bundle by name nodes will assemble them into a single data structure, although the ordering of the elements is not easily accessible, so it's not perhaps a useful thing to do unless you just want to handle all the items of data as a single entity.

[jgcode]

QUOTE (Gavin Burnell @ May 22 2008, 02:45 AM)

Sounds more like Interleave 1D Arrays to me.

If the inputs to be multiplexed are all of the same type then probably want to build them into a 1D array. If each input is a single scalar number then the node 'build array' will do this. If the inputs are each arrays, but you want the output to take the first element from each input and then the second and so forth, then 'interleave 1D arrays' is what you want.

If the inputs to be multiplexed are all different types. the the bundle/bundle by name nodes will assemble them into a single data structure, although the ordering of the elements is not easily accessible, so it's not perhaps a useful thing to do unless you just want to handle all the items of data as a single entity.

Its kinda hard to answer the question with limited detail but if you need the dynamically flexibility of an array coupled with the flexibility of handling different datatypes try the Named Funcitonal Global Variable structure.

Someone showed me this structure once and it is really handy as a tagged dynamic store.

You assign names to each data element in a store then access them using this name. If a data element exists in a named location it will replace that element, if not it will add it to the array.

Even if you are only going to use one datatype this can be handy to track elements by name rather than by index. If you do only use one datatype I would place the NFGV in a wrapper VI so I would not have to handle the variant conversions each time.

[

[gb119]

QUOTE (jgcode @ May 22 2008, 12:55 AM)

Its kinda hard to answer the question with limited detail but if you need the dynamically flexibility of an array coupled with the flexibility of handling different datatypes try the Named Funcitonal Global Variable structure.

Someone showed me this structure once and it is really handy as a tagged dynamic store.

You assign names to each data element in a store then access them using this name. If a data element exists in a named location it will replace that element, if not it will add it to the array.

Even if you are only going to use one datatype this can be handy to track elements by name rather than by index. If you do only use one datatype I would place the NFGV in a wrapper VI so I would not have to handle the variant conversions each time.

This sort of data structure is known as a dictionary or associative array or hash array or map in other languages. There's actually quite a few ways of implementing it in LabVIEW. There's a discussion of the efficiency and speed of a number of these in http://forums.lavag.org/Map-implemented-with-classes-for-85-t8914.html' target="_blank">this thread. My personal preference is to use the attributes of a variant to store the data. Essentially, rather than having two arrays, one of data and one string keys, you have a single variant on the shift register and then use the Get/Set/Delete Variant Attributes to manage the stored data - this seems to be one of the most speedy mechanisms up to several 1000 keys.

[jgcode]

QUOTE (Gavin Burnell @ May 22 2008, 07:39 PM)

This sort of data structure is known as a dictionary or associative array or hash array or map in other languages. There's actually quite a few ways of implementing it in LabVIEW. There's a discussion of the efficiency and speed of a number of these in this thread. My personal preference is to use the attributes of a variant to store the data. Essentially, rather than having two arrays, one of data and one string keys, you have a single variant on the shift register and then use the Get/Set/Delete Variant Attributes to manage the stored data - this seems to be one of the most speedy mechanisms up to several 1000 keys.

Thanks for the link. Variant attributes are one of those things that I know were there but I have never really used. I recoded the FGV subVI and I like the simplicity. I did a quick benchmark (Pentium M 1.6GHz, 1GB RAM) on a simple three element cluster (similar to error cluster) just to see. Compared to the data arrays, it seems no big perfomance hit sub-1000 - but after that then it really start to matter.

Some great reading here and here too.

Seems the NFGV or using arrays may be old school and the variant attributes are the way to go to manage a DB!

Thanks Gavin.

NFGV_LV851.zip

Code is in LV 8.5