Greetings everyone, I am a first-time contributor but a long-time follower of these forums. Despite searching extensively, I have been unable to find a solution to our current issue. Our system is experiencing a communication failure with a crucial electrical component, as indicated by SCADA due to the status bits. I have thoroughly inspected and replaced the radio, as well as verified the other components. The contractor has made changes to the Reference Address (referencing RJ45 CPU ETHERNET data) and the variable tag. However, the old and new variable bits are not showing any changes in Data Watch. Despite checking the logic and variables, I am unable to pinpoint the problem. No rewiring has been done, the only component replaced was the radio, which has been confirmed to be communicating properly. I am able to remotely access all devices on the system post-installation. Testing MODBUS to Ethernet switches to radio has not revealed any issues. There is ladder logic in place that alters the Read/Write status bits every two minutes, resulting in updated data. However, the status turns FALSE immediately after a 3-second delay. Is there a way to access diagnostics for the channel transmitted through the Ethernet port on the CPU? Despite monitoring the reference bit via Data Watch, there have been no changes apart from the 2-minute force reset. PLC Diagnostics have been checked with no reported issues. Any insights or suggestions would be greatly appreciated. Thank you, Michael.
Are the communications between the SCADA system and the PLC experiencing issues? Have the status bits being monitored shown any discrepancies since the contractor's work on the equipment? Are these status bits influenced by the PLC's logic?
The PLC is continuously polling READ/WRITE requests during a forced reset and only updating every 2 minutes. Communication between the PLC and SCADA remains stable, as confirmed by the functioning of other components.
Hi Michael, welcome to the forum and thanks for the detailed explanation. Based on your description, it seems like you've done a thorough job of troubleshooting. However, the issue might not be hardware-related if all these components have been checked. Have you considered the possibility of a software or a protocol issue? For example, is it possible that there's a mismatch in the communication settings between your SCADA system and the PLC or an issue with the addressing scheme? I'd suggest a detailed examination of your MODBUS protocol settings and a review of the timing and control bits in your ladder programming. Additionally, checking for firmware updates or performing a factory reset may help if the problem is due to a software glitch.
Hi Michael, welcome to the forum! It certainly sounds like you've been pretty thorough in your troubleshooting. One thing that comes to mind is the time delay - if the status bit goes false after 3 seconds, I wonder if there's a timing issue somewhere in the ladder logic? Particularly as you mention the forced reset every 2 minutes. Also, for the Ethernet diagnostic, you could make use of diagnostic commands (read/write) specified in your PLC's Ethernet module documentation. An Ethernet/IP explicit message could help to diagnose non-communicative modules. It's just a shot in the dark, but I hope it helps. Good luck!
Hi Michael, welcome to the forum! It's great you've done such a comprehensive job troubleshooting. Often communication issues can be traced back to the network environment rather than individual devices, so perhaps examining the surrounding infrastructure could be beneficial. It's notable that your data update halts after a short delay—there might be something amiss with your Timeout settings or perhaps a network bottleneck you've overlooked. Also, have you verified that the clock rate is harmonized across all devices? Regarding CPU Ethernet port diagnostics, some PLC models have built-in web servers that offer diagnostic features, but mainly it depends on the specific type of PLC you're using. Can you provide more details about the PLC model?
Hi Michael! It sounds like you’ve really delved deep into troubleshooting this issue. Have you tried checking the configuration settings on the CPU itself? Sometimes, even small misconfigurations can lead to communication hiccups. Also, if you haven't already, it might be worth temporarily bypassing the Ethernet part and connecting directly to the radio to see if the problem persists there; isolating components can sometimes reveal unexpected issues. Additionally, look into any potential firmware updates for your components that might address compatibility problems. Hope you get it sorted out soon!
Hey Michael, it sounds like you've done some thorough troubleshooting already, which is great! Have you considered the possibility of a mismatched configuration between the PLC and the radio after the changes made by the contractor? Sometimes, even small discrepancies in settings can cause communication issues like the one you're experiencing. Additionally, check if there are any updates or patches for your SCADA software that could address potential bugs in the data handling. Lastly, verifying the firewall settings on your network might also help, as sometimes these can prevent proper data flow. Good luck, and hope you get it sorted soon!
✅ 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: The communication failure could be due to various reasons such as incorrect Reference Address settings, issues with the variable tags, logic errors, or faulty components.
Answer: Answer: You can start by checking the Reference Address settings, verifying variable tag configurations, inspecting the logic for errors, and testing components for proper functionality.
Answer: Answer: Yes, you can access diagnostics for the Ethernet port on the CPU to monitor the communication channel and identify any potential issues affecting the data transmission.
Answer: Answer: The discrepancy in the status bits could be due to misconfigured settings, logic errors, or communication interruptions between components. Further investigation is needed to pinpoint the exact cause.
Answer: Answer: The immediate status change could be triggered by a specific condition or error in the logic that is causing the status bits to reset. Reviewing the ladder logic and monitoring variables closely
Join hundreds of satisfied customers who have transformed their maintenance processes.
Sign up today and start optimizing your workflow.