Issue: An anomaly was detected in the Programmable Logic Controller (PLC) where the value of the DNB word (Local:X:I.Data[x]) fluctuates rapidly and unpredictably when explicit messages are triggered alongside implicit communication (IO message). Method: The erratic behavior occurs when explicit messages are sent via devicenet using tools like RSLinx or RSLogix. Monitoring the Local:X:I.Data[x] word through RSLogix trend reveals the fluctuation. An example scenario involves an unchanged IO value when the device is idle, but the value fluctuates briefly before returning to normal at random intervals. This issue persists until explicit messages cease, resulting in a stable IO value. Details: The problematic machine comprises seven PLCs with multiple networks and devices. Testing on three PLCs showed the issue in at least one network. The problem consistently arises with Siemens Micro Master 440 Inverter and TR Electronic Encoder devices configured in DNB as polled. Various communication adjustments failed to resolve the issue, prompting the need for further investigation and potential alternative solutions.
Dear @Ken Roach, I would greatly appreciate your assistance. Thank you in advance for your help.
It appears there may be an address conflict occurring, with two instances attempting to write to the same address. If this issue arises specifically when triggering MSG instructions, it is important to closely examine the defined addresses and lengths for potential errors.
Robertmee suggests that the issue may be an address conflict, where two instances are attempting to write to the same address. If the problem occurs only when triggering MSG instructions, it is important to check the addresses and lengths carefully. Thank you for the support. This could potentially explain the error message from RSLogix. However, the issue also occurs when browsing in RSLinx. What could be causing this problem in that scenario?
Discover the benefits of browsing RSLinx before and after editing your explicit messages. Explore the advantages of using RSLinx for message clarification and optimization.
Over the years, you have shown interest in my posts regarding DeviceNet troubleshooting. Many of these posts are from twenty years ago, when I was an expert in troubleshooting multi-vendor compatibility, compliance, and reliability issues related to this popular technology. However, I no longer work for Rockwell Automation, the ODVA, or any vendors whose products you may be using. Your system is unique as it consists of both third-party devices and DeviceNet safety products, which operate differently from standard cyclic data exchange and I/O tag mapping. It is possible for the DNB to inaccurately handle explicit message responses, potentially placing the data in the wrong location within the system. Troubleshooting this issue may require a protocol analyzer to examine the data on the network and identify any disruptions. Additionally, testing the system by sending explicit messages through alternative devices on the network can help pinpoint where the problem lies - whether it's with the slave devices, the DNB, or the data routing process. Be sure to gather firmware revisions for both the ControlLogix and 1756-DNB modules, and consider utilizing other tools and resources at your disposal. This comprehensive approach will help in diagnosing and resolving the issues you are facing with your DeviceNet system.
From my experience, this anomaly could be a product of poor synchronization between your explicit and implicit communication. Keep in mind that your PLC may be overtaxed in trying to handle both types of communication simultaneously. While your Machine has multiple PLCs, remember that individual PLCs themselves have their own processing limits. In relation to Siemens Micro Master 440 Inverter and TR Electronic Encoder, you might need to delve into their individual device manuals. They could have specific timing or sync requirements which aren’t met in this setup. I'd recommend you to isolate and stress-test these devices to identify if there’s a pattern when this anomaly occurs. Lastly, don't overlook possible firmware updates which often address such miscommunication issues.
It seems like you've done pretty comprehensive troubleshooting on this issue. However, have you considered checking the cyclic load on the PLC during these random fluctuations? High cyclic loads could influence the stable execution of explicit messages. Also, you could try to limit the collision of explicit and implicit communication by separating them within different cyclic intervals if your PLC allows. Lastly, I'd check if there are any firmware updates available for the Siemens Inverter and TR Encoder, firmware issues are not uncommon and can cause communication anomalies.
It sounds like a frustrating issue you're dealing with! Given that the fluctuations only occur with explicit messages and stabilize afterward, it might be worth looking into the timing and priority of your communication cycles. Sometimes when explicit and implicit messages collide, it can cause unexpected feedback loops or timing issues, especially over the DeviceNet network. Have you considered adjusting the message timing or prioritizing the implicit messaging to see if that helps? Also, double-checking for any firmware updates on both the PLCs and your devices might uncover potential fixes as well.
✅ 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 fluctuating DNB word value in the PLC is caused by the combination of explicit messages being triggered alongside implicit communication (IO message) via devicenet.
Answer: Answer: You can monitor the fluctuation of the DNB word value in the PLC by using tools like RSLinx or RSLogix to observe the Local:X:I.Data[x] word and track its behavior over time.
Answer: Answer: The problematic machine comprises seven PLCs with multiple networks and devices, where the issue consistently arises with Siemens Micro Master 440 Inverter and TR Electronic Encoder devices configured in DNB as polled.
Join hundreds of satisfied customers who have transformed their maintenance processes.
Sign up today and start optimizing your workflow.