Keep Object names while using U16 as variable Mod1DI15:0 is there a easy way?

[~Its_Me~]

For a cRIO I need to use some IO modules with 32 IO. I think it is convenient to use human readable names (apple in picture below). 

On the other hand I do not want a lot of wires so I tend to use clusters. For the digital IO a standard option is to use a U16 to group 16 booleans.

However If I use the U16 I lose the human readable names. Is there a option to use the human readable names without wiring 32 wires for every IO module by hand to a cluster? Maybe there is a simple fast trick I can use?

[GerdW]

Hi You,

---

@~Its_Me~ wrote:

However If I use the U16 I lose the human readable names.

Is there a option to use the human readable names without wiring 32 wires for every IO module by hand to a cluster? Maybe there is a simple fast trick I can use?

---

An U16 is just an U16: there are no "labels" on its 16 bits…

So there is no "simple trick" to keep the IO pin labels when you use the (very good IMHO) option to read U8/U16/U32 ports at once.

You still can convert that U16 to a boolean array, and convert that array into a boolean cluster using your own cluster typedefinition. You can set any label you like in your own typedefinition!

[~Its_Me~]

Hello GerdW,

Thanks for the reply. I understand what you suggest. However It still feels kind of odd that one can edit the names in the module (see the text apple in the picture) which would give a good overview of the signals in your project. Which makes it easier to manage your code etc. And then I would need to make a separate typedefinition to define the signal names. If someone else has got a solution please tell. For now I think I need to use the typedefinition method you suggest. Maybe Ni could add a function to create a cluster with names when you rightclick the module.

[rolfk]

Basically, the module is a 16 bit or 32 bit digital IO module. The individual channels is part of the abstraction layer that LabVIEW FPGA generates for you under the hood to read the according port, mask out the specific bit and turn it into a simple boolean. If you read the 16 bit as an integer you get a 16 bit integer where the various bits implicitly corresponds to the according IO lines but there is no abstraction present.

Either you address the bits individually by their names (and LabVIEW FPGA will generate the according bitmasking and unmapping under the hood while compiling the FPGA bitfile) or you access them directly as binary integer and get the raw data. It's an either or! There is no eating the cake and keeping it too.