Hello all, I am seeking assistance with a PLC system integration task. I have approximately 10 different PLCs with unique IP addresses from which I need to gather communication signals. These signals need to be collected and processed in a central PLC. I am considering whether I should standardize the IP addresses or if it is possible to proceed without changing them. Additionally, I am looking for guidance on assigning I/O addresses in each PLC. For example, if I have an I3.7 signal in three separate PLCs, how can I ensure these signals are correctly transmitted to the central PLC without interference? Any advice or suggestions would be greatly appreciated!
To ensure seamless communication between PLCs on the same subnet, make sure each PLC has a unique IP address. This will allow you to create produced/consumed tags or utilize MSG instructions to transmit necessary data to the central PLC without any interference. Be sure to use different destination tags for your IO tags to prevent any overlap. Additionally, consider using a CIP data Table Write on each PLC to efficiently transfer data to the central PLC.
If the PLCs are located on the same subnet, the setup process becomes simpler. To ensure seamless communication between PLCs, it is essential to organize the network access for each PLC within the main PLC's IO tree. For 1756-L7 processors, this includes the ethernet module, backplane, and processor. Likewise, for L8 processors utilizing the onboard ethernet port, only the PLC needs to be included. The same applies to Compact Logix with onboard ethernet. To integrate these PLCs successfully, you must add them offline and then download the configuration. Once the PLCs are all incorporated into the IO tree and communicating effectively, establish a consumed tag in the main PLC to retrieve data from each of the other PLCs. In turn, create a produced tag in each of the other PLCs that the main PLC will consume. For instance, let's consider a scenario with MainPLC, PLC1, and PLC2. Add PLC1 and PLC2 to the MainPLC's IO tree. In PLC1, set up a produced tag (such as an array or UDT) named PLC1_Produced_Tag. Similarly, create a produced tag in PLC2 called PLC2_Produced_Tag. In the MainPLC, generate a consumed tag named PLC1_Consumed_Tag. Connect this tag to PLC1 in the IO tree, and designate the source tag as PLC1_Produced_Tag. Repeat this process for PLC2 by creating a consumed tag named PLC2_Consumed_Tag and defining the source tag as PLC2_Produced_Tag. Ensure consistency in the data structure (whether it's a single tag, array, or UDT) between the Produced and Consumed tags in each PLC. They should have an equal number of bytes. Transfer the necessary data from the consumed PLCs to the produced tags in ladder logic, and manage the data in the Main PLC to align with the logic requirements.
When dealing with large amounts of data in industrial automation, utilizing the MSG instruction is often more effective than using Produced/Consumed tags. However, it's important to consider network configurations - if PLCs need to be on different subnets, implementing a NAT device like a Stratix switch can help facilitate communication.
JamesCash suggested that while Produced / Consumed tags may work well for small amounts of data, using the MSG instruction is preferable for handling larger amounts of data. It is important to note that both options assume that the PLCs are on the same subnet. In cases where the PLCs are on different subnets, a NAT device like a Stratix switch can be used. Why limit yourself to only a "few" bits? In our experience, we have successfully used a standard UDT to transfer hundreds of DINTs and Reals to all PLCs within a plant. Implementing stacked messaging can be more challenging when communicating with multiple PLCs, and there is a risk of buffer overrun.
In a comment, robertmee questioned the use of a "few" in regards to transferring data between multiple PLCs in a plant. Implementing stacked messaging can pose challenges, especially when communicating with several PLCs, potentially leading to buffer overruns. If the equipment shares the same data and allows for the use of a standard UDT across all logic, then why not opt for that approach? However, this may not always be feasible, leading to the tedious task of creating P/C tags for each processor. In my experience with machinery, I have not encountered buffer overflow issues when using the MSG instruction.
It sounds like a complex but interesting task you've got on your hands. Standardizing IP addresses could improve your overall organization but isn't necessarily required, it's more about your personal preference and ease of operation. Now as to your question about the I/O addresses, I would consider creating a mapping scheme in your central PLC. This will allow you to assign unique identifiers to signals from each PLC, thus ensuring they don't get mixed up. For instance, you could prefix the I3.7 signal from each PLC with an identifier for that controller (e.g., PLC1_I3.7, PLC2_I3.7, etc.) This would make it much easier to track where each signal is coming from and ensure they are processed correctly.
It sounds like a challenging yet interesting project! You can definitely proceed without standardizing the IP addresses, but it will complicate the communication setup. A robust approach would be to implement a communication protocol that includes the source IP in the transmitted data to ensure clarity in the signals. For the I/O addressing, consider using a prefix or suffix to differentiate signals from each PLC. For instance, you could label them as PLC1_I3.7, PLC2_I3.7, etc., at the central PLC, which will help you avoid interference and maintain clarity when processing data. Using a structured method will help streamline the integration and improve maintainability in the long run!
It sounds like you've got a pretty complex setup! Standardizing your IP addresses could certainly simplify communication and help avoid any potential conflicts, but it's not strictly necessary if you're careful with how you manage the data flow. You can implement a protocol where each PLC tags its signals with a unique identifier before sending them to the central PLC, allowing you to distinguish those I3.7 signals even if they come from different sources. Just make sure you define a consistent mapping for those tags on the receiving end. Additionally, using a common communication standard (like Modbus or MQTT) could also help streamline this process. Good luck with your integration!
✅ Work Order Management
✅ Asset Tracking
✅ Preventive Maintenance
✅ Inspection Report
We have received your information. We will share Schedule Demo details on your Mail Id.
Answer: - Standardizing the IP addresses can simplify network management and troubleshooting tasks. However, if changing the IP addresses is not feasible, it is possible to proceed without standardization by setting up proper routing and subnet configurations.
Answer: - To avoid interference when transmitting signals from multiple PLCs, it is recommended to assign unique I/O addresses for each signal in every PLC. This ensures that the signals are correctly routed and processed by the central PLC without conflicts.
Answer: - Some best practices include ensuring proper network segmentation, setting up secure communication protocols, implementing redundancy measures, documenting network configurations, and regularly monitoring network performance to ensure smooth data transmission and system operation.
Join hundreds of satisfied customers who have transformed their maintenance processes.
Sign up today and start optimizing your workflow.