Hello everyone, currently I am attempting to establish communication between a ControlLogix PLC and a PC using Modbus TCP AOI. The Client resides on the PLC while the Server is located on the PC. To ensure compatibility, I have upgraded my ControlLogix firmware to version 20.19 and my Ethernet module 1756-EN2T to version 5.009. I followed Rockwell's manual for guidance, but encountered error code -9 indicating a connection failure. Are there any troubleshooting suggestions to rectify this issue? I have successfully connected a TCP client on my computer to the server running on another PC. The manual suggests placing the instruction in a periodic task, but can it also be used in a continuous task? What are the potential drawbacks of doing so? Any advice on this matter would be greatly appreciated. Thank you for your help!
Troubleshooting connectivity issues between a CL PLC and a ModbusServer on a PC can be complex, especially when a second PC can successfully connect. The first step is to validate the settings of the ModbusClientAOI on the PLC, including the IP address and port number. Next, confirm if the PLC can establish a TCP/IP connection with the first PC on Modbus Port 502. Consider factors like LAN setup, involvement of a router, and potential port filtering from devices like routers or PC antivirus software. For a more in-depth analysis, consider using Wireshark or a similar application to compare packet transmissions between the second PC and the PLC. Check if the packets from the PLC are visible on the LAN of the first PC and on the PLC's own LAN. This thorough approach can help pinpoint any discrepancies and facilitate troubleshooting to ensure successful connectivity.
If you're experiencing issues with your code, it may be due to incorrect parameters like DestAddress or LocalSlot. An incorrect LocalSlot could trigger errors in creating messages. To troubleshoot, expand the MSG_Connect message configuration to view the error code. Remember, if your PC and PLC are not connected on the same network, make sure to configure a gateway address for the EN2T module to ensure proper communication.
I will provide additional details. The 1756-EN2T module is set up with the IP address 192.168.1.1, while the PC's Ethernet connection is configured as 192.168.1.180. I have used this IP address and port 502 in the DestAdress setting. The 1756-EN2T module is linked to a Stratix 6000 managed switch via an Ethernet cable. From the Stratix 6000 switch, there is another Ethernet cable connecting to a Stratix 2000 unmanaged switch, and finally, a cable runs from the unmanaged switch to the PC. This network setup was established prior to my involvement, so I am unfamiliar with how the Stratix 6000 switch is configured.
Upon my observation, it seems that your PC is unable to establish a connection on port 502. To resolve this issue, it is recommended to conduct a Wireshark trace and enable port mirroring on your switch. Another possibility is that the AOI was duplicated instead of being imported, which could lead to similar errors occurring.
According to Contr_Conn, your PC may be blocking connections on port 502. To troubleshoot, try capturing a Wireshark trace and ensure port mirroring is enabled on your switch. Another possibility is that someone may have mistakenly copied the AOI instead of importing it, leading to similar errors. I recently connected my PC directly to a Stratix 6000 switch, bypassing the unmanaged Stratix 2000. This resulted in a successful connection after enabling it. However, when I tried the old method involving two switches (plc and pc), the connection failed. Even when I replaced the Stratix 2000 switch with another unmanaged switch, the same issue persisted. Is there a configuration setting on the Stratix 6000 switch that needs to be adjusted? Additionally, I confirmed that port 502 on the PC is open and functioning properly.
It sounds like you've taken care of the basics quite well. Error code -9 is indeed indicative of a failed connection, so let's focus on that. First off, you might want to double-check if both your devices are on the same subnet and if there could be any firewall or antivirus software blocking the communication. It could also be a routing issue, so check if your routing tables are correctly set up as well. In terms of placement of the instruction, it could work in a continuous task but it's generally not recommended. This is because continuous tasks can monopolize the processor's time and potentially cause scan time issues or consume memory. If unexpected issues arise, troubleshooting them could also be more complicated. Periodic tasks exist precisely to help manage resource allocation more effectively, which tends to be crucial in such communication set ups.
Hi! It sounds like you've taken all the right steps, but still hit a roadblock. Sometimes, the error code -9 is triggered by network issues, perhaps some connectivity settings? You could check that all your network settings are correctly matched between your PLC and PC. As for your question about placing the instruction in a continuous task, assuming your network and processing can handle the load, it's theoretically possible - the main concern would be the performance impact, as it could cause your PLC to slow down due to the constant demands of communication. It's usually best to stick to a periodic task that matches the rhythm of your application. Keep tinkering and don't give up!
It sounds like you've done a good amount of troubleshooting already, but I'd suggest a couple more things you might want to look into. First, check to ensure that your firewall isn't restricting the connection between the PLC and the PC. Secondly, regarding the instruction placement, while it can technically be placed in a continuous task, a periodic task is more advisable--the Modbus TCP AOI is resource-intensive and running it continuously could impact the PLC's overall performance. A periodic task allows better regulator control over resource allocation. Also be sure to check the execution time of AOI, if it's high, it might be an issue. Finally, always double check your Modbus TCP settings to ensure that they match the settings on both devices.
I'd suggest double-checking your IP settings first to confirm that both the PLC and PC are in the same subnet and there's no firewall blocking comms. On the PLC side, make sure that no other clients are consuming all of the connections available. Regarding your question about the task, yes, technically it is possible to place the instruction in a continuous task, but it might hinder the scan time efficiency since it runs the instruction every cycle. A periodic task provides a more controlled execution, which is recommended especially for high traffic network applications. Experimenting with different routines and observing the results can provide helpful insights. 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: Possible causes could include incorrect firmware versions, improper configuration settings, network issues, or compatibility issues with the Modbus TCP AOI.
Answer: Answer: Some troubleshooting suggestions could include double-checking the configuration settings, verifying network connectivity, ensuring firmware compatibility, and examining the error logs for more specific information.
Answer: Answer: While the manual may recommend placing the instruction in a periodic task for optimal performance, it may still be possible to use it in a continuous task. However, doing so could potentially impact the overall PLC performance and responsiveness.
Answer: Answer: Running the Modbus TCP instruction in a continuous task could lead to increased scan times, reduced PLC processing speed, and potential delays in other critical tasks running on the PLC. It is recommended to follow Rockwell's manual guidance for best practices.
Join hundreds of satisfied customers who have transformed their maintenance processes.
Sign up today and start optimizing your workflow.