Unicast or Multicast on an EtherNet/IP I/O Connection: the Checkbox and What It Decides

Module fault 16#0106 appeared on the second controller’s listen-only copy of a 1734-AENTR drop, and the string underneath it reads “Module owned and configured by another controller. Module may accept only one connection if Unicast is used.” The owning controller had been upgraded, its module entries recreated in a newer Logix Designer, and every one of them came back with the unicast box ticked because that is the default. Nothing was wrong with the network, the addressing or the adapter. One checkbox in the owner’s project had quietly removed the second controller’s ability to listen.

Unicast for one listener. Multicast the moment a second controller, a redundancy pair or a listen-only connection needs the same data.

What the checkbox actually changes on the wire

Implicit I/O is UDP, and the only question the checkbox answers is who the destination address belongs to.

With unicast, the module sends its input data to one IP address, the owning controller’s, and a second controller wanting the same data would need the module to open a second connection and send a second copy. With multicast, the module sends one stream to a multicast group address and every device that has joined that group receives it, so two controllers cost the module one transmission instead of two. That is the whole difference, and every consequence below comes out of it. The design considerations manual’s guidance is to select unicast whenever possible, for reasons that are about the network rather than about the controller: it reduces bandwidth, it simplifies switch configuration, and it lets produced and consumed tag traffic cross subnets, which multicast will not do without routing that most plants do not have. The same manual is equally clear about the other side — multicast is the more efficient method for transmitting data with multiple consumers and in redundancy applications — and notes that some facilities block multicast packets outright, which settles the question before you get to open the dialog.

Unicast is the Logix Designer default. That is convenience, not a recommendation for your particular rack.

The adapter’s effort is the same on both sides. What changes is whether a second controller is allowed to exist at all.

The listen-only rule, in the words of the fault code

The one fact worth carrying away from this article is printed inside the explanation of a module fault rather than in any configuration chapter.

The general instructions reference, describing 16#0106, says that if the owner is connected to the module using a unicast connection over EtherNet/IP, other connections to the module fail because the owner controls the one connection; that if the owner is connected using multicast, unicast connections to the module fail for the same reason; and then states the fix in one line — configure both the owner and the listen-only connection as multicast. Both ends. Setting the listen-only controller to multicast while the owner stays unicast produces the same fault with the roles reversed, and that is the version that eats an afternoon, because the person doing the work is looking at the project that is failing rather than at the project that is working. The ownership rules underneath come from the I/O and tag data manual: an input module can have several owners, provided every additional owner carries identical configuration data and an identical communication format, while an output module allows exactly one owner and rejects any second attempt. A listen-only connection writes no configuration at all, which is why 16#0110 exists — it cannot connect until an owner has configured the module first.

Change the owner’s project. The listen-only project is the one reporting the fault and the wrong place to fix it.

Listen-only also inherits the owner’s timing, and 16#0111 is how that arrives: for a listen-only connection, an RPI out of range means the owner’s RPI is slower than the one this controller requested.

Produced and consumed tags, where the arithmetic changes

A produced tag is the case where multicast stops being a preference and starts being a connection count.

The EtherNet/IP Network Devices manual spells out what a multicast produced tag costs: a produced tag connection with two consumers has a connection to each consumer, each tag passing through the device uses one connection, and all EtherNet/IP devices support as many as 32 produced multicast connections. So a cell controller producing four tags to five consumers each is using twenty of that budget before any I/O is counted, and the module’s total connection pool is shared with everything else routing through it. Unicast changes the calculation in the other direction, and is the reason it exists for produced tags at all: it lets the traffic span subnets, which is the only way to get a produced tag from a cell on 192.168.10.x to a line controller on 192.168.20.x without a multicast-capable router. The trap on that path has its own code. Fault 16#0108 covers a connection type that the far end does not support, and the general instructions reference lists the specific case: you configured a consumed tag to use a unicast connection and the producing controller does not support unicast connections.

Older producers do not all speak unicast. The consumer is where the fault shows and the producer is where the limitation lives.

Six situations, two answers. The second row is the one that produces 16#0106 and the only row where both ends have to be changed together.

What multicast costs the switch, and what to do about it

A multicast stream with nobody managing it is a broadcast stream with extra steps.

A switch that does not snoop IGMP forwards every multicast frame out of every port in the VLAN, so a rack of I/O at a 10 ms RPI reaches the HMI, the engineering laptop, the vision system and the printer, all of which discard it after their network stacks have looked at it. On a flat plant network with a few hundred devices that is the failure people describe as “the network got slow after we added the new cell”. The management is not complicated — IGMP snooping enabled on the switches carrying the traffic, and exactly one querier on the subnet so that group membership is refreshed rather than timing out — but it has to be somebody’s decision, and on a network with no managed switches at all the honest choice is unicast wherever the topology allows it. That is what the design considerations manual is pointing at when it says unicast simplifies Ethernet switch configuration: it does not remove the need for a managed switch, it removes the need for anyone to have configured one.

One querier per subnet. Two queriers is a different argument and a worse one.

The adapter sends the same number of frames in both cases. The difference is how many devices have to receive and discard them.

What to do next

Go through the I/O tree of the owning controller and write down, for each remote module, how many controllers need that data. Anything with one reader stays unicast. Anything with a listen-only partner, a redundancy chassis or a second line controller gets multicast set at both ends in the same sitting, because changing one end is how 16#0106 is produced rather than cleared. If the answer comes out multicast on a network whose switches nobody has logged into, that is a switch job before it is a controller job, and PLC networking: switches, VLANs and DLR rings is where it starts. The RPI you pick alongside the checkbox decides how long a drop stays invisible, which is covered in EtherNet/IP setup, RPI and faults, and the codes that appear when any of this goes wrong are listed in Allen-Bradley I/O faults and their causes. For a redundant pair specifically, multicast is not optional in the way it is elsewhere — redundant PLC systems and ControlLogix pairs explains why the second chassis has to hear the same data.