What Is a Produced/Consumed Tag on EtherNet/IP?
When two controllers need to share data continuously - not a one-shot message but a live value updated every cycle - produced and consumed tags are the EtherNet/IP mechanism that does it without either controller acting as the other's I/O. This page explains what produced and consumed tags are, how the producer/consumer connection between controllers forms, and how they differ from a MSG instruction.
Produced/Consumed Tags in one line: A produced tag is a tag one controller makes available on EtherNet/IP for others to receive; a consumed tag is the matching tag another controller receives it into. Together they form a cyclic controller-to-controller connection, updated at an RPI like I/O, that shares live data peer-to-peer without either controller scanning the other as a device.
How Produced/Consumed Tags Work
A produced tag is declared in the producing controller as data it will make available to the network, along with how many consumers may connect to it. A consumed tag is declared in each receiving controller, naming the producing controller and the tag it wants. When the consuming controller comes online it opens a CIP connection to the producer, and from then on the producer sends the tag's value cyclically at the negotiated RPI, exactly like an I/O connection. The value simply appears in the consumed tag, refreshed continuously.
The transport is the same producer/consumer, Class 1 implicit connection that carries I/O - the data multicasts or unicasts from producer to consumer on the RPI with no per-update request. This is why produced/consumed tags feel like I/O between controllers: they are I/O, just with a controller on both ends instead of a controller and a remote rack. The data type and size of the produced and consumed tags must match, or the connection is refused, the same size-match rule that governs assemblies.
Because it is a connection, it has a timeout. If the producer stops producing, the consumer's connection times out and the consumed tag goes to a defined bad state, which the receiving logic can detect and act on. This makes the mechanism suitable for interlocks between controllers, where knowing that the peer has gone silent is as important as the value itself.
Produced/Consumed Tags Versus a MSG Instruction
The alternative way to move data between controllers is a MSG instruction, which sends an explicit read or write on demand. The two are not interchangeable. A MSG instruction fires when its rung tells it to and completes when the response arrives - it is on-demand, asynchronous, and carries explicit-message overhead. Produced/consumed tags are cyclic, connection-based, and low-overhead once established, refreshing automatically forever without any rung logic.
The rule of thumb follows directly. For a value that must be shared continuously and reliably - a live setpoint, a status other controllers interlock on - produced/consumed tags are the right tool, because they refresh every RPI and fault visibly on loss. For an occasional transfer - a recipe download, a command sent once - a MSG instruction is simpler and does not consume a permanent connection. Choosing the wrong one gives you either stale data or an unnecessary flood of explicit traffic, the same trade covered in implicit versus explicit messaging.
Where Produced/Consumed Fits in the System
Produced/consumed tags live entirely between controllers; SCADA does not participate in the connection. A monitoring platform such as Merobix reads whatever tags a controller exposes over a standard protocol, and a consumed tag is an ordinary tag in the receiving controller once the connection is running. If a consumed value looks stale in SCADA, the diagnosis is at the controller-to-controller connection - has it timed out, has the producer stopped - not at the SCADA layer, which is only reflecting the tag.
Because the mechanism reuses the same producer/consumer connection as I/O, its network behavior is governed by the same considerations: RPI sets the update rate and the timeout, and multicast versus unicast delivery affects switch load when several controllers consume the same produced tag. Those are the same trade-offs described in multicast versus unicast I/O, applied to peer data rather than remote racks.
Frequently Asked Questions
What is the difference between a produced and a consumed tag?
A produced tag is data a controller publishes on EtherNet/IP for others to receive, declared with a maximum number of consumers. A consumed tag is the matching tag in a receiving controller that names the producer and the tag to receive. The two form one cyclic connection: the producer sends the value at an RPI and it appears, continuously refreshed, in the consumed tag.
Should I use produced/consumed tags or a MSG instruction?
Use produced/consumed tags for data that must be shared continuously and reliably, such as a live setpoint or an interlock status - they refresh every RPI and fault visibly if the producer goes silent. Use a MSG instruction for occasional, on-demand transfers like a recipe download. Produced/consumed is cyclic and low-overhead; MSG is on-demand and carries per-message overhead.
What happens to a consumed tag if the producer stops?
The consumed tag's connection times out, based on the RPI and its multiplier, and the tag goes to a defined bad or last-state condition that the receiving logic can detect. This is by design: because it is a real connection, loss of the producer is visible, which is what makes produced/consumed tags suitable for interlocks where a silent peer must be treated as a fault.
Automation services
Need help turning this into a working system?
Merobix integrates SCADA, programs Allen-Bradley and Siemens PLCs, and designs and fabricates industrial control panels.
Meeting requests are reviewed before confirmation.