How to Troubleshoot Communication Error in MSG Instruction for Transfer of Data between 1756-L73 and 1756-L71 Controllers

Question:

Hello everyone, I am facing challenges in setting up a message instruction to transfer data from a 1756-L73 controller to a 1756-L71 controller. The communication path from the first controller is 1,4,2, IP address, 1,0. Despite my efforts, I am encountering a communication failure error. Can anyone provide guidance on troubleshooting this issue? It's worth noting that both controllers are on the same subnet. Thank you for your assistance.

Top Replies

To gain a better understanding of the pathway, additional information is required. Based on the current data, the pathway appears to include VLAN X, 2, IP address x.x.x.x, and has a flow of 1 with no delays.

To ensure clarity, let's confirm the setup. Your initial controller utilizes an Ethernet module located in Slot 4 within the nearby chassis, while the second controller is situated in Slot #0 within the distant chassis. Could you confirm the specific Ethernet module model being used in the local chassis - is it 1756-EN2T or ENBT? Additionally, what error message are you encountering? One potential troubleshooting step to consider is adding the remote ethernet module and controller to the local controller's I/O Configuration. While not mandatory, this can streamline the path selection process for easier operation.

The IP address setup appears to be correct for an Ethernet module in Slot 04 of the source controller's chassis and a CPU in Slot 00 of the destination controller's chassis. The 1's represent the Backplane port, while the 2 signifies the Network Port of a 1756-ENxT module. It is important to accurately count the slots, starting with 00 as the leftmost slot. To test the CIP Path and connectivity, configure a message to execute the Get Identity service, which all controllers and modules can respond to. Recording the .ERR and .EXERR error values for the MESSAGE control tag can help diagnose network connectivity issues, CIP Path addressing problems, or errors related to the tag's syntax, spelling, scope, or external access settings.

I have another example that mirrors your situation closely. It's important to skip the initial step. Begin by inserting the ENxT module into Slot 4. Make sure to connect Ethernet port 2 and configure the IP Address for Backplane 1. The PLC should be positioned in Slot 04,2,x.x.x.x,1,0. This setup is vital for seamless operation.

CIP Paths consist of pairs of [Port, Address] values, always. When the 1756-ENxT module is included in the I/O tree of the CPU's chassis (even if not currently utilized for I/O purposes), clicking on the module triggers the insertion of the initial "1, slot" hop into the CIP Path string within the MESSAGE control tag. Interestingly, entering "1, " manually will prompt RSLogix to automatically replace it with the module name. The first hop in the CIP Path sequence, starting with Port 1 of the backplane and then moving to the 1756-ENxT slot, is always necessary when using an Ethernet module external to the CPU. It is imperative to include this initial step and cannot be omitted when connecting to the 1756 backplane.

It sounds like you've got a tricky issue on your hands. Are both controllers set up to communicate on the same network protocol? Identifying the common and preferred network protocol is crucial here. Also, check if there is any firewall that might be blocking the communication between them since they reside on the same subnet. If you've already tried these, remember to verify the routing table's configuration to ensure that it correctly routes the traffic between the controllers.

More Replies →

Streamline Your Asset Management
See How Oxmaint Works!!

✅   Work Order Management

✅   Asset Tracking

✅   Preventive Maintenance

✅   Inspection Report

We have received your information. We will share Schedule Demo details on your Mail Id.

To add a comment, please sign in or register if you haven't already..   

Frequently Asked Questions (FAQ)

FAQ: 1. What could be causing a communication error in a message instruction for transferring data between 1756-L73 and 1756-L71 controllers?

Answer: - There could be various reasons for a communication error, such as incorrect path configuration, IP address settings, network issues, or programming errors.

FAQ: 2. How can I troubleshoot a communication failure error between two controllers on the same subnet?

Answer: - To troubleshoot the issue, you can check the path configuration, verify the IP addresses, ensure proper network connectivity, and review the message instruction setup for any mistakes.

FAQ: 3. What steps can I take to resolve a communication error when setting up a message instruction for data transfer between Allen-Bradley controllers?

Answer: - Some steps to resolve the issue include checking the routing path, confirming the IP addresses, verifying subnet settings, examining the message instruction configuration, and testing the network connection.

FAQ: 4. Are there specific considerations to keep in mind when setting up a message instruction for transferring data between different Allen-Bradley controllers?

Answer: - Yes, considerations include ensuring the correct path configuration, setting up proper IP addresses, configuring the controllers on the same subnet, and troubleshooting any communication errors that may arise during the setup process.

Ready to Simplify Maintenance?

Join hundreds of satisfied customers who have transformed their maintenance processes.
Sign up today and start optimizing your workflow.

Request Demo  â†’