Hello everyone, I am encountering a peculiar issue with a simple DeviceNet setup, comprised of two identical Sick laser rangefinders functioning as slaves and a DeviceNet to CanOpen converter serving as the master for DeviceNet and a slave for CanOpen. Periodically, the readings from the rangefinders become stuck on a specific value even when the machine is in motion, leading to errors. Eventually, after a short period of time (seconds or minutes), the node resumes normal operation and the value is updated. Initially, the converter was suspected as the source of the problem and after confirming with the supplier that everything was functioning correctly, the issue persists. I am now considering the possibility of a DeviceNet issue. Could you offer any insights on this matter? Additionally, I am unsure if the DeviceNet configuration includes a trunk line or solely consists of drop lines. Is it feasible for DeviceNet to operate in this setup?
During network scans, I encountered a problem with devicenet nodes dropping in and out, which was ultimately caused by a burnt resistor. To address this issue, it is recommended to conduct resistance checks between the signal lines.
I discovered a crucial terminal resistance missing on the trunk line, leaving only one present. Stay tuned for an update on Friday regarding the results.
Unfortunately, the machine is still exhibiting the same behavior as before, but there has been a slight decrease in the frequency of the error. Can you provide any suggestions on potential alternative causes for this issue?
To ensure proper functionality, verify that the resistance between CAN H and CAN L is at 60 ohms. Ensure that V- and shield are connected at the power source. Confirm that the 24 VDC power supply is rated appropriately and that the total amperage does not exceed the power supply rating. For optimal performance with DeviceNet, consider using a dedicated power supply. It is advisable to manually set baud rates using DIP switches rather than relying on automatic detection. Engage DIP or switches for consistent settings.
Although I am now retired, I created a comprehensive training course on troubleshooting Devicenet issues for my team of technicians in the past. This course is available in Spanish. If you are interested in gaining access to it, simply send me a private message with your email address.
It sounds like you’re dealing with a frustrating issue! Based on what you’ve described, it could be a communication timeout or a data congestion problem on the DeviceNet, especially if the readings get stuck periodically. It might help to review the network configuration to ensure that each device is properly addressed and that the baud rate settings are consistent across all devices. Also, check for any electrical noise in your setup, as that can sometimes cause erratic behavior. As for your question about the trunk line and drop lines, DeviceNet typically uses a trunk and drop architecture, so it’s definitely feasible to have both in your configuration. You might want to consider doing some signal observations to see if you can capture any anomalies when the readings freeze. Good luck!
It sounds like you’re dealing with a frustrating issue! Since the readings from the laser rangefinders stick intermittently, I’d suggest checking the network termination and the overall health of the DeviceNet connections. In a DeviceNet setup, both trunk and drop lines can be used, so if you're only using drop lines without proper termination at the end of the trunk, that could lead to signal integrity issues. Also, ensure that your baud rates and node addresses are configured correctly. It might help to capture some diagnostics or logs from your DeviceNet traffic to see if there’s any indication of communication problems during those stalls. Good luck!
It sounds like you’re facing quite a challenge with your DeviceNet setup! Since the readings from the Sick laser rangefinders get stuck intermittently, it could be worth checking the communication settings and ensuring that there are no timeouts or polling issues with the master-slave configuration. Sometimes, electromagnetic interference or poor connections can also lead to erratic behavior in the readings. Regarding your question about the configuration, DeviceNet can definitely operate with just drop lines, but incorporating a trunk line can enhance reliability, especially over longer distances. It might be helpful to run some diagnostic checks on the network to see if there are any communication faults or check for any stray wiring that could be contributing to the problem. Hopefully, you find a solution soon!
It sounds like a frustrating issue you're dealing with! Since you’ve already confirmed that the converter is working correctly, it might be worthwhile to check the termination resistors on the DeviceNet bus, as improper termination can lead to communication problems that could cause those stuck readings. Also, consider examining the wiring and connections for any signs of wear or interference, as noise in the network can disrupt message transmission. Regarding your configuration, DeviceNet can indeed operate without a trunk line if you're just using drop lines; just ensure that each node is properly addressed and that the total length and number of devices align with DeviceNet specifications. Have you tried monitoring the network traffic or logs to see if there are any errors or timeouts? That could provide more clues. Good luck with it!
It sounds like a frustrating situation you're dealing with! The symptoms you're describing—stuck readings from the rangefinders—could indeed indicate a temporary communication loss or a configuration issue within the DeviceNet setup. Consider checking the baud rates and termination resistors to ensure everything is properly configured, as mismatches can lead to erratic behavior. Regarding your question about the configuration, DeviceNet can absolutely work with drop lines, but a trunk line can enhance reliability, especially in longer setups. Perhaps test each segment of your network individually or try swapping out cables to rule out any physical layer issues. It might also be worth monitoring the network for any error codes that could provide further clues. 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: - The readings becoming stuck on a specific value could be due to communication issues within the DeviceNet network. It's essential to troubleshoot the network configuration and connections to resolve this issue.
Answer: - Start by checking the network configuration, connections, and addressing settings for the DeviceNet devices. Ensure that all devices are properly powered and that there are no interruptions in communication.
Answer: - While DeviceNet typically uses a trunk-line/drop-line topology, it is possible to operate with solely drop lines in certain setups. However, ensuring proper termination and network design is crucial for reliable communication.
Answer: - The delay in response time could be attributed to network traffic, configuration settings, or potential conflicts in the DeviceNet setup. Conducting a thorough inspection of the network components and settings can help identify and resolve the issue.
Join hundreds of satisfied customers who have transformed their maintenance processes.
Sign up today and start optimizing your workflow.