Hello all, I am currently experiencing a communication problem between two different PLCs. The Master PLC is Guard Logix 5069 with the IP address 192.168.1.1, while the chiller has a Compact Logix (model unknown) with the IP address 192.168.0.30. I have been utilizing the MODBUS TCP CLIENT AOIs provided on the Rockwell website, but have encountered communication issues. Initially, the Modbus transfers the data properly, but after a few minutes, it faces Overlap and Overload problems, disrupting the communication flow. We have tried adjusting the polling interval on both ends, but to no avail. I also attempted to use the msg instruction, which failed due to the IP address mismatch. Any suggestions on resolving these Modbus client issues or alternative methods for achieving uninterrupted communication would be appreciated. Thank you.
When working with PLCs, using Ethernet I/P for communication is recommended over Modbus. To ensure successful communication, it is crucial that both PLCs are on the same subnet. Additionally, the configured path and data types in both PLCs must match accurately for the MSG instruction to function properly. Possible subnet mask for both PLCs should be considered during the setup process.
Hello, the problem at hand involves the chiller supplier not requiring the devices to be in the same subnet. I am unsure of the subnet for the compact Logix, but the master PLC subnet is 255.255.255.0. Considering that Modbus is an Ethernet protocol, it may not be the best solution. Do you have any suggestions for this issue? Additionally, what are your thoughts on utilizing a Gateway for data transfer? Thank you.
It appears that the default IP address for the chiller, 192.168.1.1, needs to be updated to match the IP subnet of the rest of the equipment. Consider using a MSG instruction or produce/consume method for seamless integration.
A device set with an IP address of 192.168.1.1 and subnet mask of 255.255.255.0 is unable to directly communicate with a device configured with an IP address of 192.168.0.30, unless connected through a router. The primary reason being that they do not belong to the same IP subnet. To resolve this issue, it is essential to evaluate your Ethernet infrastructure and connectivity setup. If a router or NAT device is present between these devices, understanding their configuration is crucial. It is generally advised against using Modbus/TCP for communication between two Rockwell Automation controllers, as the controllers inherently support regular Tag read/write operations without the need for additional complications.
It sounds like you're dealing with a pretty tricky situation. One way you might try to circumvent the Modbus issues you've been experiencing is by employing a data concentrator. This acts as an intermediary between the two PLC's, effectively managing traffic to avoid data overload and contamination (Overlap). Also, regarding the IP mismatch, it could help to configure your PLCs with subnet masks that allow them to communicate, even though they are on different subnets. For example, if your Master PLC has a subnet mask of 255.255.0.0 it should be able to communicate with 192.168.0.30. Lastly, you could attempt to use Ethernet/IP communication; Rockwell does a great job in supporting Ethernet/IP, including explicit messaging. Don't forget the old trick too of restarting both the PLCs and the software, sometimes just a restart can resolve such issues. Good luck!
✅ 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: Answer: Overlap and Overload problems during Modbus communication can be caused by issues such as network congestion, improper configuration settings, or communication errors between the PLCs.
Answer: Answer: To resolve Modbus client communication issues, you can try troubleshooting steps such as checking network configurations, adjusting polling intervals, verifying IP address settings, and ensuring proper data transfer protocols are used.
Answer: Answer: Yes, alternative methods for achieving uninterrupted communication between PLCs include using different communication protocols, implementing error-checking mechanisms, utilizing quality of service (QoS) settings, and ensuring network stability and reliability.
Join hundreds of satisfied customers who have transformed their maintenance processes.
Sign up today and start optimizing your workflow.