ControlLogix Controller Tag Aliasing I/O in Remote Rack

So I did another project in ControlLogix (v15.65 Redundancy) not too long ago where I had a controller tag aliased to a digital input module (IB32) sitting in another rack just for I/O. The alias was set to TS_IO:I.Slot[1].Data where TS_IO was the ControlNet network connection to the I/O rack.

This way, I didn't have to add the IB32 to the I/O configuration but would still be able to see the data. Since a different controller "owned" the I/O, it also had the added benefit that when I forced the I/O for testing, all of the different controllers (3 in total) that aliased the input card would see the forced value as well.

Fast forward to today and I'm using a similar setup. I have two controllers (v20 Redundancy) aliasing an IB16 digital input card in another rack that is "owned" by a third controller. The trouble I'm facing is that the two controllers with the alias tag are not reading the input data at all. I'm not seeing any errors on any of the modules, ControlNet is happily scheduled, and I'm kind of left scratching my head. I can go online with the controller that owns the I/O and see bits 0-6 on, but the aliased tags from the other controllers show 0 for all bits.

Now I can always just add the IB16 to each controllers I/O configuration and move on, but I'd like to understand why the alias doesn't work for this case. Other than the different modules and firmware revisions, there are only a couple of other things different between the system setups. One is that on the working system, the controller that owns the I/O is in a separate rack from the I/O. In the non-working system, the controller is in the same rack. Another is that in the working system, the controllers alias modules in the rack that don't appear in the I/O configuration, but other modules do appear in the I/O config. This means I am aliasing modules 1-7, but have modules 8-13 in the I/O config. In the non-working system, I don't have any modules at all in the I/O config. I have the ControlNet card that expands to show the back plane but nothing else.

I'd be interested to hear anyone's thoughts on why this doesn't work like I expected. Perhaps I'm doing something stupid?

The fact that you have Alias tags is probably a red herring: the problem is in the I/O definitions, not in the Alias feature. So let's remove that from the discussion.

The tag you are describing "TS_IO:I.Slot[1].Data" is the Rack Optimized data object for a ControlLogix chassis.

These get created in the Controller-scope tag database whenever you put a 1756 series I/O chassis into the I/O tree with a Rack Optimized or Rack Optimized - Listen Only connection.

It does not get created when you put a 1756 series I/O chassis into the I/O tree with a connection type of "None".

Which type of connection to you have from your listening controller to the 1756-ENBT module in that I/O chassis ?

The proper way to do this is to put the I/O connections to the rack and to each module in your I/O tree, but set the connection types for Listen Only.

It sounds to me like the owning controller has no reason to put the data onto the ControlNet network (it's local to those modules, right ?) so there's no reason for the data to be produced.

It might also be an issue with the fact that these are Redundant controllers. A connection over EtherNet/IP to an I/O rack or I/O module is slightly different if the originator is a Reundancy system versus when it's a single controller.

I'm not sure I'm following everything you are saying. With the normally controller, I understand that the TS_IO:I and TS_IO:O data is generated when I create the CN2R module (named TS_IO) between the local CN2R and the CN2R in the rack containing the I/O module. Currently this is set to rack optimized.

Only the I/O controller has the IB16 as part of its I/O configuration and the DI module is setup with a comm format of "input data."

I have a ControlNet link between the controller rack and the I/O rack (which contains a controller) setup because I will use a few produced/consumed tags between the two controllers. I know for sure if I add the IB16 module into my local configuration and set it to "input data - listen only" it works just fine, but I just am not convinced I have to yet. I can post up some screenshots of the configurations if that might be helpful.

I admit this is one of those basic ControlLogix things I never took the time to fully investigate.

I believe that the basic "RackName:I.Slot[x]" tags are created for the Chassis object. If the Chassis object does not also include a connection, no actual data shows up in those tags if the Chassis object is all that's defined.

If you add a Module or Rack Optimized connection to that chassis object, then the RackName:I.Slot[x] contains the same data as the actual RackName:s:I.Data[x] tags.

I always moved on to the next step, where I properly set up the I/O modules and gave them a Module or Rack Optimized connection, then used the module's own .Data tags. I never experimented with having only the Rack Optimized connection because on the systems I was building, those tags seemed to function only as placeholders until the module was defined.

There's an interesting explanation of this that might be more clear than mine in the RA Knowledgebase Article ID 17846.

Again, I can't explain why your explanation of observed behavior appears to be different than mine.

But since we agree that when you create a Module Object with a Listen-Only Rack Optimized connection you get the desired functionality, I'd say that's the way to go.

So I just did some experimenting with my two controllers trying to get data using an alias reference without the I/O module being present in the configuration. As soon as I added the module into the configuration in one of the controllers, all of them could see the data, even the ones without the module in the configuration. This leads me to believe that at least one controller on the network is required to have the I/O module in the configuration when (using rack optimization).

Thinking about my previous project, that does make sense since I had the entire I/O rack being read using rack optimization for one of the four controller pairs, while the other four just had the aliased references with no configuration.

Thanks for the links to the articles about rack optimization as they did help to shine some light on what was happening and gave me the nudge to experiment a little more.