Creating shared variables bound to I/O Aliases

[JKSH]

Hello,

I'm running LabVIEW 2012. When I right-click on an .lvlib in the project explorer, there's a "Create Bound Variables" option. It's really convenient, as it automatically binds many variables to generic network-published shared variables simultaneously.

However, it doesn't seem to support network-published I/O Aliases -- those libraries just don't show up in the dialog. I know that the I/O Aliases themselves work fine, because I was able to bind them manually, and then read them from my PC.

Is there a way to automate the binding process for I/O Aliases?

Thanks

[JoeySpinella]

Hi JKSH,

Where are these I/O Aliases located? In another project on your computer? On a remote computer? Can you give an example of how you created them in the first place?

The create bound variables function allows us to see the variables as they are named on the shared variable engine, but will not allow us to see Aliases that are assigned across the network.

On the same topic, I did find a community example that allows Programmatic Creation of I/O Aliases and Network Variables with LabVIEW 2009

[JKSH]

Hi Joey,

Thanks for the link. At a quick glance, it looks like a lot of work -- beneficial for large projects, but mayby not for smaller ones. But, I'll study it further to see if it's helpful to us.

Anyway, my project contains a PC target and an RT (CompactRIO) target. The RT target hosts two kinds of variables: "Network-Published" and "I/O Alias" (although the I/O Aliases are also network-published -- they're visible on the Distributed System Manager)

From the Project Explorer, I created a new library under the PC target and did Right-click -> "Create Bound Variables..." -> "Project Items"

The dialog lets me choose other variables from my project to bind to. However, when I navigate to my RT target, I can only see the the "Network-Published" libraries, not the "I/O Alias" libraries. It's very odd -- If I choose "Network Items" instead of "Project Items", I can see my I/O aliases. This path isn't ideal however, as I'm likely to have to change the IP address of the CompactRIO. I'm curious about the reason why the I/O Aliases are inaccessible from "Project Items"?

[JoeySpinella]

Hi JKSH,

I/O Aliases are bound to I/O Variables within the same target. They derive their identity entirely from the I/O variable they are bound to and make it easy to rename and access the values of an I/O Variable.

It is expected behavior that we would not see the Aliases in Project items when we use the Create Bound Variables function. It is also expected that we would see the Aliases on the network and in DSM, since we have selected that they be network-published.

Why do you need to create bound variables to the I/O Aliases instead of the I/O Variables when they will hold the same values?

[JKSH]

Hi Joey,

It's mainly for maintainability.

I/O Variables are grouped physically by chassis and module, not by purpose. My current project is a plant controller, using 3 CompactRIO chassis (linked by EtherCAT) and 20 C-series modules. The I/O ports for a logical part of the plant can be split across different modules (and even different chassis sometimes) -- thus physical grouping is suboptimal.

Here is our simplified system architecture:

We need variables hosted on the PC server for DSC logging, but also need variables hosted on the cRIO for robustness (e.g. in case connection with the PC server is lost).

We have 2 primary reasons to create I/O Alias libraries, instead of binding directly to I/O Variables:

1. It lets us group the variables more logically, which in turn lets us simplify our code for programmatic variable access. It's an abstraction layer between the hardware and the code. The logical groupings also help our developers better visualize the system.
2. The client has not finalized their specifications, and the I/O port mappings might change. If we use I/O Aliases, we can just change the I/O Variable that the I/O Alias points to, and that's it. However, if we bind directly to I/O Variables, changing the hardware mapping will require us to change (i) the controller code, (ii) the I/O Variable that the PC variable points to, and (iii) (technically optional, but needed for readability) the I/O Variable name

Anyway, since it is possible to (manually) create bindings to I/O Aliases, I'm surprised to hear it's expected behavior that we would not see the Aliases in Project items when we use the Create Bound Variables function

[JoeySpinella]

Hi JKSH,

Let me create a similar system here and see if I see the same behavior. I will see what I can figure out and post back.

[pallen]

I realize this is a 5 year old post.  But I'm curious how things turned out.