brands · South Africa
Produced and Consumed Tags: Logix Data Exchange Guide
Learn Logix produced and consumed tags: data layouts, controller connections, RPI, status, duplicate records and practical troubleshooting for SA learners.
Produced and consumed tags share data between supported Logix controllers through configured connections. The producer owns the outgoing data; a consumer receives the selected produced tag. This can support cyclic status exchange without a separate MSG instruction for every transfer, but the connection is only one part of the application. Data meaning, freshness, ownership and failure behaviour still need a deliberate design.
For South African learners working with Allen-Bradley equipment, this topic belongs after controller tags, data types and basic network troubleshooting. This guide covers standard educational examples, the evidence needed for a native configuration, and a fictional record-processing exercise. It does not provide a safety-network design or claim that browser practice reproduces a Logix controller-to-controller connection.
What produced and consumed tags actually solve
Suppose one controller calculates a group of process-status values and another needs to observe them. A produced tag defines an outgoing interface; the consumed tag identifies the source and receives the corresponding data. The receiving application can then interpret that data according to a shared agreement.
That agreement matters as much as the connection. A field named Ready could mean that a unit is powered, that a sequence is idle, that material is available or that an operator has granted permission. If each team assumes a different meaning, values can transfer correctly while the overall system behaves incorrectly.
Start with a short interface description. State the producer, intended consumers, field meanings, units, update expectations and response to unavailable data. Identify which controller owns each decision. If information must return in the other direction, define that separately rather than treating a consumed value as a shared variable that both controllers may freely control.
The Allen-Bradley learning route introduces the surrounding skills. Review controller and program tag scope first if the distinction between local application data and a controller-level interface is still unclear.
Confirm the native requirements in the right manual
Rockwell's Produced and Consumed Tags programming manual, publication 1756-PM011N dated September 2025, requires controller-scoped tags and matching data types, including user-defined layouts. It describes a 500-byte limit for standard produced/consumed tags and creation while offline. Its safety-tag requirements differ and should not be inferred from this standard-data tutorial.
Use the manual together with the actual controller and network documentation. Record both catalogue numbers, firmware revisions, engineering-software release and the intended route. A general statement that both devices are CompactLogix does not establish every supported setting or limit.
The manual's consumer setup includes identifying the producing controller in I/O Configuration and specifying the remote produced tag. It also warns against multiple consumed tags in one controller receiving the same produced tag from another controller. Build the configuration from the documented requirements, not by repeatedly adding connections until a value appears.
These are configuration facts to verify in a controlled project. They do not justify downloading a training project into operating equipment. Preserve the existing project and use the site's authorised change and test process when the work moves beyond an isolated learning environment.
Design a small, readable interface before adding fields
For a fictional study, define an outgoing record with an exercise identity, revision number, sample sequence, item count and a state code. Document the allowed state codes and the meaning of the count. Decide whether the count is cumulative, per batch or since the latest exercise reset.
Avoid exposing unrelated internal variables just because they are convenient. A clear interface lets the receiving application depend on documented meanings while the producer's internal logic evolves. Conversely, a change to an interface field's type or meaning should trigger a coordinated review of both sides.
A useful field table includes name, type, units, valid range, owner and invalid-data handling. “Integer” alone is not a complete description. The consumer needs to know whether a negative count is valid, whether zero is meaningful, and whether a missing or stale record may be used for any decision.
Do not claim compatibility from matching type names. Two projects can both contain a user-defined type called LineStatus with different members. Compare the actual layout and its version. The data conversion guide is useful when units and numerical representations differ, but conversion must be an explicit part of the interface rather than an unnoticed assumption.
Separate communication status from application validity
A connected consumer is evidence about the communication relationship. It does not prove that the producing application has completed its calculation, that a count is current, or that the remote sequence is in the state your local logic expects. Treat connection health and application data validity as related but separate observations.
Rockwell's Consumed Tag Connection status help distinguishes connection to the producer from the producer being in Run mode. It also identifies whether a CONNECTION_STATUS member is included. Use those documented observations rather than concluding that a plausible number proves the whole exchange is healthy.
For example, an unchanged item count can be entirely valid when no new items are completed. It can also be an old value retained after an interruption. A separate application sequence or timestamp may help distinguish those situations when the interface design defines how it changes and how it is evaluated.
On a display, label unavailable remote data clearly. Do not replace an uncertain status with a reassuring green indicator or convert missing information into a numerical zero. The FactoryTalk View binding guide explains how the HMI path introduces its own identity, access and presentation checks after the controller exchange.
RPI is a communication setting, not an end-to-end promise
The requested packet interval concerns the data connection's update behaviour. It is not the same as the producer's application task period, the consumer's use of the data, an HMI refresh interval or the time required for physical equipment to respond. A small number in the configuration cannot by itself establish an end-to-end response guarantee.
Build a timing requirement from the application. Identify when the source changes, when the outgoing record becomes ready, when it is transferred and when the receiver makes its decision. Include the applicable controller, communication and network constraints. Where performance matters, verify the complete path through a representative and controlled test.
Avoid universal settings such as “always use 50 ms.” The appropriate configuration depends on the supported devices and the application's needs. A smaller requested interval can increase communication work; it does not create a blanket assurance that every value will be fresh enough for every use.
Also distinguish resource types. Connection capacity and traffic load are not interchangeable measurements. Reducing an interval changes update demand, while adding consumers can change connection and traffic requirements. Review both through the relevant documentation rather than blaming every communication issue on an unspecified shortage of bandwidth.
Keep a coherent record when values change asynchronously
An application may update related fields at different points in its execution. If another context reads part of an old record and part of a new one, the resulting combination may never have existed as a complete intended state. Define how a coherent outgoing record is assembled and how the receiving logic obtains a stable working copy.
Rockwell's Logix design considerations manual discusses buffering produced and consumed data with CPS instructions. It also describes sequence indicators or return handshakes for recognising and acknowledging new data. CPS has execution implications, including inhibited interrupts during the copy, so apply the documented instruction and design guidance to the actual target.
Do not treat a copy instruction as a universal cure for application-level inconsistency. If the source record was assembled from incompatible observations, copying it consistently preserves that problem. Agree when the record is complete and what its identity represents before designing the transfer.
For a study project, keep the outgoing structure small and describe the capture point in plain language. A reviewer should be able to answer, “Which observations belong to this record?” If that answer depends on guessing when several unrelated routines happened to run, improve the interface contract before adding more fields.
Worked exercise: distinguish a new record from a repeated value
This paper exercise is fictional and does not execute a native produced/consumed connection. It models one receiver handling records identified by session and sequence. The exercise's rules are deliberately limited so that expected results can be calculated and reviewed.
Within session A, valid sequence numbers increase. A newly accepted record replaces the receiver's current study record. An identical repeat of the current sequence is ignored. A repeated sequence with a changed payload is a conflict. A lower sequence is treated as old data. A new session requires an explicit reset of the study's comparison context.
| Incoming record | Expected study result |
|---|---|
| A, sequence 10, count 50 | Accept first record |
| A, sequence 11, count 50 | Accept new record, even though count is unchanged |
| A, sequence 11, count 50 | Ignore identical duplicate |
| A, sequence 11, count 51 | Flag conflicting duplicate |
| A, sequence 9, count 49 | Ignore old record |
| B, sequence 1, count 0 | Hold for explicit new-session handling |
The second row is the key distinction. The count has not changed, but the record identity has. A receiver that uses only count changes to detect new data would miss a valid update. Conversely, incrementing a completion total every time the same record is observed would count duplicates as new work.
After the first five rows, the last accepted record is still A, sequence 11, count 50. Two records were accepted, one identical duplicate was ignored, one conflict was flagged and one old record was ignored. The B record remains outside the active session until the study's reset rule is deliberately applied.
Extend the exercise without inventing protocol guarantees
Explicitly start session B in the paper model, then accept B, sequence 1, count 0. Zero is valid because the exercise defines count as a non-negative integer. A missing count remains invalid. A negative count fails the stated range rule. These outcomes follow the teaching contract, not an automatic behaviour promised by Logix.
Now consider a sequence jump from 1 to 4. The receiver can identify a gap, but it cannot reconstruct records 2 and 3 from the latest count alone. Depending on the real application's purpose, missing intermediate records may be acceptable or may require a different data-handling design. A latest-status interface and an event-history interface solve different needs.
The exercise does not implement sequence rollover. If a real finite-width counter can wrap, define and test that behaviour explicitly. Do not interpret every numerical decrease as a reboot, and do not assume every new low number is old data. Session identity, rollover rules and restart handling must agree across the interface.
Add a test for a lost connection while the last record remains visible. The record may still be useful as labelled historical context, but it must not silently remain trusted current data. Decide the permitted response for the actual process through its engineering requirements; this article's paper model does not specify machine actions.
The PLC program testing exercises can support the habit of recording input sequences and expected outcomes. Use them for educational reasoning, then validate native communication separately on suitable supported equipment.
Request, acknowledgement and completion need distinct meanings
Some interfaces exchange more than status. A controller may request a recipe change or ask another unit to prepare for a transfer. In that case, specify what acknowledgement means. It could mean the request was received, accepted for processing or completed. Those are different events and should not share an ambiguous label.
Give the transaction a documented identity so that a delayed acknowledgement cannot accidentally complete a newer request. Define how duplicates, rejection, timeout and restart are handled. A timeout tells the requester that the expected response was not observed in the defined time; it does not prove that the remote operation never happened.
Avoid assuming that switching to a MSG instruction automatically solves these application semantics. Likewise, a cyclic produced tag can carry a structured request, but the receiving logic still needs a clear processing contract. Choose the communication mechanism and the application protocol together, based on the actual requirements.
A useful learner assessment asks the student to explain a delayed response in a timeline. Show the request identity, observations and decision at each point. The sequencer logic guide provides a related way to separate states and transitions without treating a communication success as physical completion.
A systematic native troubleshooting sequence
First record which exchange fails and whether the issue affects one tag, one producer or several controllers. Capture controller identities, project revisions and the relevant diagnostic state. A description such as “the tags are zero” is an observation about values, not a diagnosis of the connection.
Check the configured producer route, remote tag name, scope and data layout against the intended interface. Review consumer configuration and supported limits. Then distinguish a connection problem from a producer that is connected but not executing the expected application behaviour.
Use the documented status facilities and exact error information from the installed software. Do not assume a layout mismatch always fails silently or always fills data with zero. Actual diagnostic and value behaviour must be observed and interpreted through the relevant controller and firmware documentation.
If the issue followed a change, compare both interface revisions and both deployed projects. A change on only one side can invalidate an earlier successful test. Restore or revise the configuration through the approved process, then repeat the cases that originally demonstrated correct behaviour. The industrial communication troubleshooting guide helps structure the evidence.
What a South African training course should demonstrate
Ask the provider which controllers, network and software release the course uses. A meaningful practical lesson should identify the two endpoints, explain the shared data contract, establish an exchange and investigate a prepared fault. Watching two numbers match once is a limited demonstration.
Request individual access or a clear rotation plan when hardware is shared. Learners should be able to inspect both projects and explain the difference between a producer's calculation, a transfer and a consumer's decision. Ask whether the course includes disconnected, stopped-producer and changed-interface observations in a controlled lab.
For learners travelling from another South African city or province, verify the actual venue and timetable before booking. Compare the full cost, including software access, travel and accommodation, against the specific skill needed. The PLC course cost guide for South Africa helps organise that comparison without pretending that every course includes the same practical depth.
For preparation, explore Allen-Bradley-style logic practice. It can support understanding of logic and data organisation within its documented educational scope. It does not replace Studio 5000, vendor networking tools or an actual controller-to-controller acceptance test.
Questions about produced and consumed tags
Are produced and consumed tags the same as HMI tags?
No. This topic concerns a configured controller-to-controller data exchange. An HMI can read and present controller information through its own communication path, but its object binding and runtime context need separate checks. A correct HMI display does not by itself prove the intended exchange between two controllers.
Do the producer and consumer tag names need to look identical?
The consumer must correctly identify the remote produced tag, and the data types must satisfy the documented compatibility requirements. Keep the local name and remote reference clearly recorded. Similar names are a documentation convenience, not a substitute for checking the actual configured source.
Does a healthy connection mean my count is fresh?
It establishes one aspect of communication health. Fresh application data depends on the producer's behaviour and the interface contract. An unchanged count can be current, while a changing field can still have the wrong meaning. Define identity, update expectations and validity explicitly.
Should I always use produced/consumed instead of MSG?
Compare the exchange pattern, compatibility, timing, connection requirements and maintenance needs. Do not select by a blanket rule that one is always faster or lighter. The application still needs clear ownership and handling for missing, repeated or delayed information whichever mechanism is chosen.
Can this tutorial be used for safety tags?
The worked model covers ordinary educational data handling. Safety tags have additional documented requirements and belong within a properly engineered safety application. Renaming a standard structure or adding a status field does not transform this exercise into a validated safety interface.
What should I ask an AI assistant about a failed exchange?
Provide a sanitised description of the controller generations, software versions, interface layout, expected behaviour and observed diagnostics. Ask it to separate facts from hypotheses and identify the relevant manual sections. Verify any suggested configuration change against the actual documentation and authorised test procedure.
Finish with a clear interface handover
Keep the interface table, source and consumer identities, configuration revisions and test results together. State the accepted timing and validity requirements, who owns changes and what the consumer may infer from each status field. Record unresolved questions openly rather than hiding them behind a successful screenshot.
For a learning portfolio, include the six-row record exercise and explain why identical payloads can still represent new records, why a duplicate must not be counted twice, and why a new session needs an explicit rule. For a real installation, add the native configuration and controlled acceptance evidence required by the project. The result should let another person understand the exchange without guessing what either controller intended.