In continuation of our articles on ODVA CIP and EtherNet/IP protocols, the DeviceNet Protocol is a widely used industrial communication network that allows devices to communicate seamlessly in a manufacturing environment. It is an industry standard developed by the Open DeviceNet Vendors Association (ODVA) and runs on top of the Controller Area Network (CAN) protocol. In this comprehensive guide, we will delve into the key features of the DeviceNet Protocol and provide a detailed understanding of its architecture and connection types.
The DeviceNet Protocol offers several key features that make it a preferred choice in industrial automation. It can support up to 64 nodes per network, which handles most process automation use cases. Another notable feature of the DeviceNet Protocol is its real-time communication capability. It provides deterministic data transmission, ensuring that critical data is delivered with minimal delay. This is crucial for applications that require precise synchronization, such as motion control and robotics.
The DeviceNet Protocol also supports peer-to-peer and master/slave communication models, allowing devices to communicate directly with each other or through a central controller. This flexibility enables efficient data exchange and control strategies tailored to specific application requirements, allowing seamless integration of various devices such as sensors, actuators, drives, and controllers in complex manufacturing environments. As a CAN-based industrial network, the DeviceNet Protocol inherits CAN's proven reliability in noisy industrial settings, making it a dependable choice for factory-floor deployments. Organizations undertaking digital transformation services often integrate the DeviceNet Protocol with modern IIoT gateways to bridge existing CAN-based industrial network infrastructure with cloud-connected monitoring systems.
To understand the internal workings of the DeviceNet Protocol, it is essential to map its protocol stack to the Open Systems Interconnection (OSI) model.
DeviceNet OSI Layer Mapping
The DeviceNet Protocol operates at the physical and data link layers of the OSI model. At the physical layer, it utilizes the standard CAN protocol to transmit data over a twisted-pair cable. The data link layer handles message framing, error detection, and retransmission. The DeviceNet Protocol specifies the transport and network layers while the higher layers of the OSI model, including session, presentation, and application layers, are defined by the ODVA CIP (Common Industrial Protocol).
Thus, it is possible to seamlessly integrate the DeviceNet Protocol with other ODVA-based industrial protocols such as EtherNet/IP, ControlNet, and CompoNet with changes from the transport layer. ODVA provides a comprehensive framework for data exchange and device management between these sister protocols.
The DeviceNet Physical Layer is responsible for transmitting data between devices. It uses a two-wire, non-polarized, and shielded twisted-pair cable to establish communication. The cable carries both power and data signals (V+, V-, CANH, CANL, and Shield), simplifying the wiring process and reducing installation costs.
The DeviceNet Physical Layer supports multiple data rates — 125 kbps, 250 kbps, and 500 kbps — allowing for flexibility in different application scenarios. The bus topology is typically linear with distances supported up to 500 m for 125 kbaud, 250 m for 250 kbaud, and 100 m for 500 kbaud. DeviceNet Protocol devices can either support isolated or non-isolated transceivers. The DeviceNet Physical Layer can be run over thicker cables for larger distances. The bus must be terminated with a 121-ohm resistance at each end.
Designing hardware that meets DeviceNet Physical Layer requirements demands careful attention to transceiver selection, cable impedance, and termination. Manufacturers building DeviceNet Protocol-compliant products rely on Embien's electronic manufacturing services for prototype assembly, signal integrity validation, and volume production of CAN-based industrial network hardware.
As is commonly known, CAN supports an 11-bit format and 29-bit format. The DeviceNet Protocol uses only the 11-bit mode. Of these, only 6 bits are needed for node addressing as there are going to be a maximum of 64 nodes. The rest of the 5 bits are used to group the messages into 4 groups. This CAN-based industrial network addressing scheme maps to CAN-ID as captured below.
DeviceNet CAN ID Mapping
Because CAN assigns higher priority to lower CAN-IDs, Group 1 has the highest priority and Group 4 the lowest in this CAN-based industrial network arrangement. Group 1 messages are typically used for real-time I/O connections, though explicit communications can also be done over that. The higher bit allocation of Message ID enables uniform bus-access priority for all devices in the CAN-based industrial network.
Group 2 messages are reserved for Master/Slave communications and for Network Access State Machine management. Group 3 messages are used for Unconnected Explicit Messaging Requests as well as Device Heartbeat and Device Shutdown Messages. Group 4 messages are primarily for diagnostic and management purposes. The DeviceNet Protocol has provision for detecting duplicate MAC IDs and managing them dynamically.
As we have seen earlier, CIP allows for Explicit Messaging between two peers in a Master-Slave relationship. Devices can initiate a connection with an Open Explicit Messaging Connection Request and terminate them with a Close Connection Request. The client device sends a request to the server device, and the server device responds with the requested data. This communication model is widely used for configuration, diagnostics, and device parameter exchange in the DeviceNet Protocol.
When there is no need for a long-term connection, the Unconnected Message Manager (UCMM) can be used to process Unconnected Explicit Requests and Responses. UCMM enables devices to initiate communication with any other device on the network, providing flexibility for dynamic device integration and efficient use of network resources. Industrial device communication between engineering tools and DeviceNet Protocol nodes typically relies on UCMM-based explicit messaging during commissioning and diagnostics phases.
I/O Connections form the backbone of DeviceNet Protocol communication, enabling the exchange of input and output data between devices. Devices can be configured as either input or output devices, depending on their role in the system. Input devices provide data to the network, while output devices receive data from the network.
The DeviceNet Protocol supports both cyclic and acyclic data exchanges. Cyclic data exchanges occur at regular intervals and are used for real-time control and monitoring. Acyclic data exchanges, on the other hand, are event-driven and are typically used for configuration and diagnostics. To establish an I/O connection, it is essential to first open an Explicit Messaging Connection with one of the intended endpoints of the I/O Connection. Then an I/O Connection Object instance must be created with a Create Request and configuration of the Connection instance. With this, the originator can start sending the I/O data. I/O connections in the DeviceNet Protocol can be either point-to-point or multicast, where a single transmission is consumed by many nodes.
The DeviceNet Protocol incorporates a predefined Master Slave Connection Set (MSCS) that simplifies the configuration process. The Master Slave Connection Set defines a set of parameters that govern the behavior of devices on the network, such as the number of input and output bytes, connection timeouts, and error handling.
The Master Slave Connection Set allows for plug-and-play integration of devices, as the configuration parameters are predefined and standardized. This streamlines the setup process and reduces network and processing overhead. The Master Slave Connection Set is particularly valuable in large-scale deployments where consistent industrial device communication behavior across hundreds of nodes must be guaranteed without manual per-device configuration.
As an extension of CIP, the DeviceNet Protocol employs the Object Class model for device configuration and management. The DeviceNet Object Class defines a set of related attributes that represent the functionality and capabilities of the interface. The attributes provide detailed information about the device, such as its MAC ID, Baud Rate, Bus status, etc.
The rest of the CIP object library and profiles are applicable for DeviceNet Protocol devices. This Object Class model allows for easy device integration and provides a standardized framework for device management. It enables seamless interoperability between different devices and simplifies the development of software applications that interact with DeviceNet Protocol devices. Consistent industrial device communication behavior is guaranteed by the object model, making it straightforward for control engineers to build SCADA and HMI integrations on top of any DeviceNet Protocol network. Embien’s product engineering and electronic manufacturing services enable the development of reliable DeviceNet-enabled products from design through production.
The DeviceNet Protocol remains a robust choice for CAN-based industrial network deployments, offering a well-defined DeviceNet Physical Layer, a practical Master Slave Connection Set for streamlined commissioning, and reliable industrial device communication through CIP-based messaging. Its proven track record in factory automation continues to make it a dependable foundation for connecting sensors, actuators, and controllers in demanding manufacturing environments.
Embien helps manufacturers modernize legacy CAN and DeviceNet Protocol systems through digital transformation services that integrate modern IIoT connectivity and cloud-ready protocols.
Embien's electronics manufacturing services support DeviceNet Protocol-compatible device production, from prototype boards to volume manufacturing with full protocol compliance testing.
A real-world case study of building a remote monitoring and control system using industrial communication protocols for process automation.