DeviceNet to EtherCAT Gateway in Smart Mining Automation
In modern mining operations, the convergence of diverse industrial networks is a critical challenge. A DeviceNet to EtherCAT gateway serves as a powerful bridge, enabling legacy field devices to communicate seamlessly with high-speed control systems. This article dives into a real-world smart mining project where such a gateway unlocked data from weighing systems, conveyor drives, and sensors, integrating them into a centralized EtherCAT-based PLC architecture.
The Role of Industrial Protocol Gateways
Industrial communication networks are rarely homogeneous. Factories and mines often contain equipment from different eras and vendors, each speaking its own protocol. A protocol gateway is a specialized device that translates data between two incompatible networks, allowing them to exchange information as if they were natively connected. In the context of mining automation, these gateways are essential for bridging the gap between robust, low-level device networks like DeviceNet and high-performance motion control buses like EtherCAT.
DeviceNet, based on CAN bus technology, has been widely adopted for connecting simple sensors, actuators, and motor starters. It offers reliable communication, power on the same cable, and good noise immunity—ideal for harsh mining environments. EtherCAT, on the other hand, is known for its blazing speed and deterministic performance, making it the preferred choice for centralized PLCs that coordinate complex motion and real-time control. A DeviceNet to EtherCAT gateway effectively merges these two worlds, preserving investments in existing DeviceNet devices while leveraging the advanced capabilities of EtherCAT controllers.
Smart Mining Project: Background and Requirements
A large-scale mining operation embarked on a comprehensive intelligent upgrade. The goal was to achieve real-time monitoring, centralized control, and data-driven optimization across the entire production chain—from extraction to transportation and weighing. The existing infrastructure included a mix of equipment: conveyor belt drives with DeviceNet interfaces, high-precision dynamic weighing systems, and various distributed I/O modules for safety signals like emergency stops and belt misalignment sensors.
The central control system was built around a high-performance PLC (such as a Beckhoff CX series) that communicated exclusively via EtherCAT. The challenge was clear: how to integrate dozens of DeviceNet-only field devices into this EtherCAT backbone without replacing them entirely. The answer was a dedicated DeviceNet to EtherCAT protocol conversion gateway, configured to act as an EtherCAT slave on the controller side and a DeviceNet master on the field side.
Network Topology and Device Configuration
The system architecture followed a clear hierarchical model:
- Control Layer: EtherCAT master PLC (e.g., Beckhoff CX2040) running the main control logic and serving as the central data aggregator.
- Gateway Layer: DeviceNet to EtherCAT gateway, physically connected to the PLC via standard Ethernet cable and to the DeviceNet trunkline via a CAN bus interface.
- Device Layer: Multiple DeviceNet slave devices, including conveyor drive units with encoder feedback, dynamic weighing systems with 4-20mA analog inputs, and distributed I/O blocks for digital signals.
The gateway was configured for cyclic data exchange. On the EtherCAT side, a communication cycle time of 1000 µs (1 ms) was set to match the PLC’s scan rate. On the DeviceNet side, the gateway polled each slave device sequentially, ensuring that critical data like weight readings and drive statuses were updated within the required process deadlines. This dual-role operation—EtherCAT slave and DeviceNet master—allowed the gateway to present all field data as a single, coherent set of process data objects (PDOs) to the PLC.
| Device | Protocol | Role | Key Data |
|---|---|---|---|
| Central PLC (e.g., CX2040) | EtherCAT Master | System controller | Commands, setpoints |
| Protocol Gateway | EtherCAT Slave / DeviceNet Master | Data bridge | Mapped PDOs |
| Conveyor Drive | DeviceNet Slave | Motor control | Speed, status, current |
| Weighing System | DeviceNet Slave | Weight measurement | 4-byte float weight value |
| Distributed I/O | DeviceNet Slave | Digital signals | E-stop, belt misalignment |
Data Mapping: The Heart of Integration
Data mapping is the most critical step in configuring a protocol gateway. It defines how bytes from DeviceNet devices are arranged into the EtherCAT PDOs that the PLC can read and write. In this project, a byte-level mapping strategy was employed to ensure efficient use of the communication bandwidth.
The input data flow (DeviceNet to PLC) included:
- Device status words (2 bytes each)
- Weight values from the dynamic weighing system (4-byte floating point)
- Speed feedback from conveyor drives (2-byte integer, scaled to RPM)
- Digital input states (packed into bytes)
These were mapped to EtherCAT input PDOs starting at offset 0x1600. The output data flow (PLC to DeviceNet) carried control commands such as drive start/stop, speed setpoints, and weighing system tare commands. These were placed in output PDOs starting at 0x1A00.
A dedicated diagnostic channel was also configured (offsets 0x1F80–0x1F9F) to transmit communication status, error codes, and device health information. This allowed the PLC to monitor the gateway and field devices proactively, triggering alarms if a DeviceNet slave went offline or a data mismatch occurred.
One notable feature was the gateway’s built-in data type conversion. For the weighing system, raw analog-to-digital converter counts were automatically converted into engineering units (e.g., kilograms) using pre-configured scaling factors. This offloaded the PLC from performing these calculations, freeing up CPU time for more critical control tasks. Additionally, a double-buffering mechanism ensured that data was always consistent—no partially updated values were ever presented to the controller.
Key Mapping Parameters: The gateway’s configuration software allowed drag-and-drop mapping of DeviceNet I/O assemblies to EtherCAT PDOs. For example, the weighing system’s “Weight” attribute (class 0x64, instance 1, attribute 3) was linked to the first four bytes of input PDO 0x1600. Similarly, the conveyor drive’s “Speed Actual” was mapped to the next two bytes. This visual approach minimized configuration errors and sped up commissioning.
Benefits and Real-World Impact
The deployment of the DeviceNet to EtherCAT gateway delivered tangible operational improvements:
- Reduced Integration Complexity: Instead of replacing dozens of DeviceNet devices, the mine reused existing equipment, saving significant capital expenditure. The gateway handled all protocol translation transparently.
- Enhanced Data Visibility: For the first time, weight data, drive parameters, and safety signals were available in real time on the central SCADA system. This enabled better production tracking and predictive maintenance.
- Deterministic Performance: With a 1 ms EtherCAT cycle, control commands reached the conveyor drives with minimal jitter, improving belt synchronization and reducing spillage.
- Scalability: The gateway supported up to 63 DeviceNet slaves, allowing future expansion without additional hardware. New devices could be added to the network and mapped into the existing PDO structure with minimal effort.
Best Practices for Implementing Protocol Gateways in Mining
Based on this project and industry experience, here are some recommendations for engineers considering similar integrations:
- Plan the DeviceNet network carefully: Ensure proper termination, cable length, and power supply. Use a network scanner to verify device health before connecting the gateway.
- Optimize PDO mapping: Group frequently changing data together and separate less critical diagnostic data to avoid unnecessary network load.
- Leverage gateway diagnostics: Use the diagnostic channel to build a comprehensive device status dashboard in the SCADA system. This simplifies troubleshooting and reduces downtime.
- Test thoroughly: Simulate worst-case communication scenarios (e.g., high bus load, intermittent connections) to ensure the gateway handles errors gracefully without crashing the PLC.
- Document the mapping: Maintain a clear mapping table that links each DeviceNet parameter to its EtherCAT PDO offset. This is invaluable for maintenance and future modifications.
The Future of Industrial Gateways in Mining
As mining operations embrace Industry 4.0, the role of protocol gateways will expand. Modern gateways are evolving to support not only basic protocol conversion but also edge computing, cloud connectivity, and advanced cybersecurity features. For instance, a gateway could preprocess vibration data locally to detect bearing faults and send only alerts to the cloud, reducing bandwidth usage. With the rise of OPC UA and MQTT, future gateways will likely bridge legacy DeviceNet networks directly to IT systems, enabling seamless integration from the rock face to the boardroom.
The DeviceNet to EtherCAT gateway described here is a proven solution for mining companies looking to modernize without discarding reliable field devices. By providing a transparent, high-performance bridge between two popular industrial protocols, it unlocks the full potential of smart mining—improving safety, productivity, and profitability.
In summary, the successful implementation of a DeviceNet to EtherCAT gateway in this mining project demonstrates that intelligent protocol conversion is a cost-effective pathway to digital transformation. It preserves existing assets, simplifies system architecture, and delivers the real-time data needed for advanced analytics and control.
