Our system consists of an S7-300 PLC (6ES7317-2AK14-0AB0) connected to 6 profibus slaves, including 3 Lenze drives and 3 IM modules. The node addresses are 3, 4, and 5 for the Lenze drives, and 10, 20, and 21 for the IM modules. Everything was running smoothly until a sudden profibus communication error halted operations. Despite efforts to troubleshoot by checking cables, connectors, and replacing components like the IM module and CPU, the issue persists. Upon closer inspection, it was discovered that the physical IM modules differ from the ones configured in the uploaded program. This mismatch raises questions about their ability to communicate successfully and raises concerns about the sudden loss of communication with the drives and IM modules. Additionally, discrepancies in the GSD file order numbers and DP slave types further complicate the situation. This situation presents several challenges: 1. Can IM modules communicate effectively with a different configured order number than the physical one? 2. If not, why were they able to communicate before the issue occurred? 3. Why did the drives and IM module (node 20) lose communication after downloading the program from the PLC, despite only node 21 experiencing issues previously? These questions highlight the complexity of the situation and the need for a comprehensive solution to restore seamless communication and functionality within the system.
Most profibus problems are related to cable issues, specifically with the cable ends. Reconnecting the end terminals can often resolve the issue. When you mention that you have "checked" the connection, can you specify what that entails?
During our inspection, we measured the profibus loop resistance, which was determined to be 110 ohms. This measurement was conducted individually at each station and also after isolating a section, revealing a resistance of 220 ohms. Can you provide insight into the potential configuration mismatch causing this discrepancy and explain why the system was still operational?
Lack of etiquette can lead to negative outcomes.
In a recent inspection, we measured the profibus loop resistance and found it to be 110 ohms. After further testing at each station individually and disconnecting a certain section, we found the resistance to be 220 ohms. This discrepancy may be due to a configuration mismatch, but it's important to note that even with such issues, the system may still function. According to Ken, many PROFIBUS problems, especially in older machines, are often caused by faulty media. This can be attributed to an excessive number of terminators, as well as issues with connectors and devices that have built-in resistors. In some cases, nodes in the middle of the segment may become improperly terminated, leading to connectivity issues. To troubleshoot this, it's recommended to carefully inspect each PROFIBUS connector to ensure the cable shield is properly connected and that the screws for the red and green lines are securely fastened. Loose connections could result from improper installation or vibrations over time. By addressing these potential issues, you can prevent further disruptions in your system's functionality.
Ken Moore emphasized the importance of good manners leading to positive responses. As a non-native English speaker, I want to clarify that my intention was simply to seek assistance without any rudeness or disrespect. I apologize if my message came across differently.
This certainly is a perplexing situation and your detailed analysis will be valuable for anyone trying to get to the bottom of it. Regarding your first question, IM modules should ideally match the configured order number with the physical one to communicate effectively. However, it might have worked earlier because of some software-level adjustments or fall-back in place that perhaps no longer applies, has been overwritten, or has developed a fault. A possible explanation for why the entire system communication stopped after a program download could be due to the configuration errors in the PLC which have propagated throughout the system. Alternatively, it's possible that the issue with node 21 has gradually impacted other nodes due to extended periods of malfunctioning. In situations like this, it is often helpful to step back and re-evaluate the entire system setup and configurations from scratch. This includes cross-verifying the compatibility between the program configurations, GSD files, as well as the physical IM modules and drives. It might be a laborious process, but such a meticulous approach tends to expose the flaws that could be causing these persistent issues. Hope this helps!
A mismatch in the physical IM modules and the ones configured in your uploaded program might definitely lead to a communication error. Although it's strange they communicated fine before, it's quite possible an update or other alteration in your system exposed this inconsistency. Also, it could have been compensating for this discrepancy until it automatically stopped due to redundancy limits. As for your drives and IM module dropping communication post program-download, it's possible the new PLC program has a different configuration that is incompatible with nodes 20 and 21. Alternatively, there could be issues with the baud rate or bus parameters after reset. Have a thorough check of the associated parameters in your PLC program, and ensure they're in accordance with each unit's specific requirements. Overall, your best bet is to correct the discrepancy between physical and programmed IM module order number. Start there, then evaluate the state of your system once that correction is applied.
It seems you've been hit with a complex issue here, but I think I have some insights. About your first point, ideally, if you're running a system with different IM modules than those configured in your PLC program, it would potentially cause communication issues due to the mismatch. This perhaps is exacerbated by differences in GSD file order numbers and DP slave types. As to why the system was running before, it's a bit of a mystery, but it could be that there was compatibility or some form of tolerance between the modules and the PLC, allowing them to communicate until the system hit a certain condition that triggered the halt in communication. With regards to the loss of communication with node 20 after downloading the program, I suspect there might be a glitch or error in your current version of the PLC program. Alternatively, the problem could stem from the new module or CPU, if they're not entirely compatible with your system or potentially faulty. As laborious as it may seem, my recommendation would be to cross-verify every number and type in your hardware configuration, double-check the version of your PLC program, and possibly consider a rollback to a previous, stable version if the issue persists. It may be time consuming but should help you to narrow down the core issue.
It sounds like a frustrating situation, especially with all that you've already checked! To address your first question, mismatched order numbers can often lead to communication problems, as the configuration dictates how data is exchanged. It's possible the modules were able to communicate initially due to temporary alignment or compatibility in the setup, but over time, even minor changes in system load or timing could have disrupted that fragile connection. For the loss of communication after downloading the new program, it might be worth reviewing the parameters set in the software—sometimes, a misconfigured setting during this process can unintentionally affect multiple nodes. Have you considered verifying the GSD files and ensuring all settings align with the hardware you're using? That could be a pivotal step in troubleshooting the whole system.
It sounds like you've been dealing with a pretty complex issue! To address your first question, IM modules typically need to match the configured order number for reliable communication; if there’s a mismatch, that’s likely a significant factor in your current problems. However, the fact that they communicated successfully before could indicate that they were operating on legacy configurations or possibly relying on certain leniencies in the network protocol. As for why node 20 lost communication after a program download, it might be worth double-checking the configuration settings again post-download, as updates can sometimes inadvertently change parameters or affect how the nodes interact with each other. It might also help to look for any recent firmware updates for the PLC or modules that could have influenced compatibility. Good luck troubleshooting!
✅ 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: IM modules may face communication issues if the configured order number in the program does not match the physical module. It is essential for proper communication that the configured settings align with the physical setup.
Answer: Answer: The successful communication prior to the issue might be due to temporary compatibility or other factors. However, discrepancies in configuration can lead to communication errors, which might explain the sudden halt in operations.
Answer: Answer: Changes in the program or configurations during download can impact communication with different nodes. The specific impact on node 20 could be related to how the changes affected the overall network communication setup.
Join hundreds of satisfied customers who have transformed their maintenance processes.
Sign up today and start optimizing your workflow.