In industrial production activities, the quality and stability of hardware products are crucial for the safe and efficient operation of the entire production line. However, we should not overlook software configuration. Software issues can also lead to system crashes, data loss, or the inability of the production line to perform its tasks properly, which can have a significant impact on the entire production process. Therefore, in both hardware and software aspects of the industrial production environment, troubleshooting is a necessary step to ensure that equipment operates smoothly, guarantee production efficiency, and maintain safety and reliability.
Today, let’s delve into a real-world case where software configuration has affected production. Let’s make sure we do troubleshooting effectively in the future to ensure the efficiency and reliability of automated production lines!
1
Customer feedback: The equipment on-site is experiencing issues with the CN-8032-L module dropping offline, resulting in the machine triggering an emergency stop and the production line ceasing automatic operation. Manual intervention is required to restore normal operation, causing disruptions to regular production and testing. If the issue of modules dropping offline cannot be effectively resolved, it will impact the final production output.
2
After on-site communication with the technical personnel, it was confirmed that out of three production lines, two of them were experiencing the same issue of modules dropping offline at the same location. Approximately 1 second after dropping offline, the modules would automatically reconnect. The customer had previously attempted module replacements, which did not resolve the problem. An initial assessment indicated that the issue was likely not related to the module’s quality. The following troubleshooting steps were taken:
1. Updated module firmware information and program GSD files to eliminate firmware compatibility issues.
2. Replaced modules again to rule out potential individual module defects.
3. Verified network, switches, and power supply hardware information, largely eliminating hardware-related issues.
4. Modified the network structure to eliminate potential network-related factors.
5. Using filters on the power supply to rule out power-related issues.
6. Investigated and resolved any network IP address conflicts.
7. Temporarily disabled the router connecting to the external network, which reduced the frequency of drop-offs but did not completely resolve the issue.
8. Captured network packets and identified non-cyclic service data packets in Profinet, leading to PLC errors due to packet timeouts.
9. Baesd on the previous step, examined the customer’s program.
By analyzing network data packets, it was discovered that the customer was using Siemens’ Modbus communication program. During the execution of specific function blocks, they inadvertently entered the hardware identifier of one function module into the program pins. This resulted in the PLC continuously sending UDP data packets to that function module, leading to a “non-cyclic service timeout” error and causing the machine to go offline.
3
The issue in the above case differs from the typical PN communication timeout caused by network interference or interruptions. Non-cyclic service timeouts are usually related to customer programming, CPU performance, and network load capacity. While the likelihood of this problem occurring is relatively low, it’s not impossible, and troubleshooting of the program or network environment can be undertaken to address it in the future.
Software issues are often less visible, but with a collaborative and systematic approach to troubleshooting, we can identify the root cause and solve problems to ensure smooth production!
So, this concludes our technical blog for this session. Until next time!
Post time: Oct-17-2023
