One of EchoRing’s key advantages is its reliability, which is made possible by its decentralized network architecture and cooperative “echo station” protocol. Once an EchoRing network has been properly deployed, everyday operations require no further input from the user. It is for this “set and forget” functionality that R3 has dubbed EchoRing – in particular the EchoRing Ethernet Bridge module - “the wireless cable,” since it fulfills the same role as an industrial cable within an application while granting the user the flexibility of a wireless network.
That said, wireless propagation environments in industrial settings still contain many random variables; system errors and shutdowns can occasionally occur. This entry will explain the process to identify and rectify the issue in these instances.
To start, we will provide an example of a typical EchoRing use case: a mobile production line comprised of Automated Guided Vehicles (AGVs) and linked by Ethernet Bridge modules. At some point during operations an error is detected and the process halts. The user must now employ a process of elimination to troubleshoot the source of the error.
Application vs. Wireless Network Errors
The first and most important step is to determine whether the issue is an application or wireless network error. The user starts at the root of the application and reviews each EchoRing-connected machine’s diagnostic interface (in this case, the production line’s assembly robots and AGVs). All machines within an application should be pre-programmed with a suite of hardware error codes during deployment, to indicate the exact issue and facilitate client-side repairs.
If all machines are functioning correctly, the user then works outward and reviews each connected Ethernet Bridge device for its diagnostic LED color (marked by “HLT” on the casing). As covered in the Ethernet Bridge user manual:
- Green: the device is functioning correctly, according to its configuration
- Red: the device is not functional or has experienced a system error
Should the HLT on one or more Ethernet Bridge devices be red, the user reboots the device. If rebooting is unsuccessful and the light remains red, this indicates a hardware or software fault in the device itself. The user then goes down the list of troubleshooting steps included in the user manual and contacts R3 Support if a solution is not found.
Should all Ethernet Bridges in an EchoRing network display a green light and no machine error codes arise, this indicates a network connection issue rather than a hardware fault. Frequent yet random errors that cannot be reliably replicated are another sign of a connection issue.
Determine Source of Network Error with the EchoRing Health Monitor
R3 has developed a tablet-based support device called the EchoRing Health Monitor to assist the user in evaluating and resolving network issues. The Health Monitor enables users to review a network’s EchoRing nodes, whether they register in the network and the signal strength of each connection. The device also enables the user to optimize node placement by visualizing each device’s signal strength in real-time.
In the event of a network error, the user first consults the Health Monitor to determine whether all nodes are connected to the network. If not, they determine whether the disconnected node’s transmission power is sufficient by consulting the EchoRing Configuration Server.
Should all nodes be connected to the network, it is important to determine whether the signal-to-noise ratio (signal strength) is sufficient – a weak signal can result in packet loss. Please review our EchoRing Deployment entry for more details on setting a network’s Packet Loss Ratio (PLR) with the EchoRing Performance Analyzer.
Another possibility is that the network’s data rate (which is set when configuring the network’s Ethernet Bridge nodes during deployment) is too high and its set latency is too low for the application’s target reliability. In this case the solution is to re-examine the network’s prioritized traffic and determine whether this category still includes any non-essential traffic that can be removed via the Configuration Server.
Another solution is to further calibrate the application’s Modulation and Coding Scheme (MCS) to balance speed and reliability, which can also be controlled with the Configuration Server.
As mentioned, signal links between individual nodes are displayed in the Health Monitor’s UI – a red link indicates poor signal strength. This could be the result of traffic noise, self-interference or from signal fade. For more information on determining and rectifying the exact issue, see our entry on propagation effects.
Should all links between nodes be displayed as green, the user then reviews the connection history at the specific time of the network error – the link may have been red then.
Other Possible Sources of Network Errors
Interference from outside the network itself is another possibility to consider. Our entry on signal interference covers this topic in depth, including the key factors to eliminate and control for when establishing an industrial wireless propagation environment.
Lastly, it is important for the user to confirm whether the signal errors are confined to the network’s mobile wireless nodes, in this example its AGVs. Mobile nodes consistently losing reception are a telltale sign that the network layout itself requires revision. In this case we recommend reading our entry on signal roaming and the importance of backbone networks to ensure industrial grade speed and reliability.
If all else fails, the user can reach out to R3 via our online Support page. Our experts are happy to assist with any technical-related issues.