Good morning! I'm currently facing some challenges in understanding the concepts of consumed and produced tags in PLC communication. I've come across a manual that details their functionality, but I still find the purpose unclear. As I've learned, it seems that a produced tag can be created in one PLC and shared as consumed tags across multiple other PLCs. However, I’m curious why it's not simpler to create a single base tag in the first PLC and then use an Ethernet connection to daisy chain it to other PLCs, thereby accessing the same tags across all controllers. Is this not the correct approach? I would greatly appreciate any clarification on this topic. I've never worked with multiple PLCs in a single project; my experience has typically involved using one PLC per machine without connecting them together. Thank you!
From my understanding, the produced tag is designed solely for consumer visibility. When establishing the producer, you specify the maximum number of consumers that can access it. Each consumed tag outlines the data reading rate for the consumers, as well as the producer's location. Additionally, it's important to note that both produced and consumed tags continue to update even when the ladder logic is set to program mode.
Daisy chaining can significantly increase signal latency. For instance, if you have five Programmable Logic Controllers (PLCs) in a daisy chain, the signal reaching the fifth PLC will experience a considerable delay compared to the first PLC in the sequence. Additionally, if one PLC fails, it can disrupt communication for all the downstream PLCs. While I am not certain how Allen-Bradley (AB) manages the produced/consumed tags at the TCP level, it can be conceptualized similarly to a multicast system. In this setup, one PLC transmits data, which is then received by other PLCs connected to the network. This approach is similar to how I typically facilitate communication between Siemens controllers. Alternatively, you could send a dedicated message to each PLC, though this method would increase the processing time for the sender. This revised text incorporates relevant terms for better search visibility while maintaining the original message’s integrity.
Here are several discussion threads that could provide valuable insights for you. Check them out for helpful information: 1. [Thread 1](http://www.plctalk.net/qanda/showthread.php?t=96924) 2. [Thread 2](http://www.plctalk.net/qanda/showthread.php?t=98072) 3. [Thread 3](http://www.plctalk.net/qanda/showthread.php?t=87917) Best regards!
To effectively manage communication between multiple PLCs, start by configuring two controllers: 1. **Tag Production**: One controller is designated to produce a tag, achieved by checking the corresponding box in the variable configuration settings. 2. **Tag Consumption**: The second controller will consume the produced tag. To do this, add the consumer controller to the Input/Output (IO) tree, create a tag of the ‘consumed’ type, specify the producing controller, and enter the tag name along with its data type. The consuming PLC establishes a connection with the producing controller, polling the tag at regular intervals. ### Connecting Multiple Controllers Directly: The process is similar to the initial example. However, when creating the producing tag, set the maximum number of consumer connections to a value such as 20. This allows up to 20 PLCs to include the producer in their IO tree and create their own consumption tags. You can repeat this setup for any additional data you wish to produce from another controller (for instance, controller 3) that needs to be accessed by specific controllers (like controllers 8, 9, and 15). ### Daisy Chaining Controllers: This method is efficient as it reduces the number of direct connections, although keep in mind that if one controller fails, it could disrupt communication for all connected devices. Set up a tag list for each controller, which might look like this: - DINT_From_PLC1_In (Consumed tag) - DINT_From_PLC1_Out (Produced tag) - DINT_From_PLC2_In (Consumed tag) - DINT_From_PLC2_Out (Produced tag) - DINT_From_PLC3_In (Consumed tag) - DINT_From_PLC3_Out (Produced tag) Next, daisy chain the controller connections: PLC2 will consume all tags from PLC1, PLC3 from PLC2, and so on. In your programming logic, copy the tag directly from the _In variable to the _Out variable in each PLC. When PLC1 updates the DINT_From_PLC1_Out tag, it can utilize DINT_From_PLC1_In for handshaking, ensuring all other PLCs have successfully received the data. Visual aids such as diagrams can greatly enhance understanding. For example, you could represent connections with a bi-directional arrow for the first type, a circumscribed pentagon for the second (illustrated with double-headed arrows), and a single-headed arrow in one direction for the third type.
alive15 stated: Good morning! I’m struggling to fully understand the concept of consumed and produced tags. Although I found a manual that outlines their functionality, I still can't grasp their purpose. Allow me to explain: consider this as a 'Data Input/Output' system. The 'Producer' CPU generates 'Output' data specifically intended for designated 'Consumer' CPUs. In turn, these 'Consumer' CPUs 'consume' (or utilize) the data supplied by the 'Producer' CPU(s) as 'Input' data within their applications. In essence, this establishes an automatic and high-speed 'I/O Class' data exchange (at a user-defined Rate Per Interval) between multiple Logix CPUs. To the best of my knowledge, this is the only controller platform that can manage data in a traditional I/O format.
✅ Work Order Management
✅ Asset Tracking
✅ Preventive Maintenance
✅ Inspection Report
We have received your information. We will share Schedule Demo details on your Mail Id.
Join hundreds of satisfied customers who have transformed their maintenance processes.
Sign up today and start optimizing your workflow.