Technical Overview

Behind each and every benefit realized in a new prioritization. DeviceNet systems can be
control system is a significant software configured to operate in a master-slave or a
engineering investment designed to deliver distributed control architecture using peer-to-
increased productivity through improved peer communication. DeviceNet systems offer a
process control and information flow. By single point of connection for configuration and
choosing DeviceNet™ products from ODVA’s control by supporting both I/O and explicit
member companies, users can protect this messaging. DeviceNet also has the unique
investment in several ways. feature of having power on the network. This
First, DeviceNet is a proven, stable network allows devices with limited power requirements
technology designed to meet the performance to be powered directly from the network,
and reliability requirements of the industrial reducing connection points and physical size.
environment. DeviceNet uses CAN (Controller DeviceNet follows the Open Systems
Area Network) for its data link layer, and CIP™ Interconnection (OSI) model, an ISO standard for
(Common Industrial Protocol) for the upper-
Network Size Up to 64 nodes
layers of the network, DeviceNet is an open
Network Selectable end-to-end network distance
standard managed by ODVA and accepted by Length varies with speed
international standards bodies around the world.
125 Kbps 500 m (1,640 ft)
In addition, users will appreciate the seamless 250 Kbps 250 m (820 ft)
bridging and routing provided by DeviceNet to 500 Kbps 100 m (328 ft)
other CIP-based networks which currently Data Packets 0-8 bytes
include EtherNet/IP™ and ControlNet™. Bus Linear (trunkline/dropline); power and
Second, DeviceNet is supported by vendors Topology signal on the same network cable
around the world. Over 700 Vendor IDs have Bus Peer-to-Peer with Multi-Cast (one-to-many);
been issued by ODVA. The fact that so many Addressing Multi-Master and Master/Slave special case;
polled or change-of-state (exception-based)
vendors have chosen to implement DeviceNet in
System Removal and replacement of devices from
their products allows users to employ best-in-
Features the network under power
class products from vendors around the world
who are best suited to support them based on Table 1: Summary of DeviceNet Features and Functionality
application expertise and geographic coverage.
network communications that is hierarchical in
Third, DeviceNet CONFORMANCE TESTED® nature. Networks that follow this model define all
products have been certified by ODVA to conform necessary functions from the physical
to the specification and operate in open, multi- implementation up to the protocol and
vendor systems by having passed conformance methodology to communicate control and
testing at one of ODVA’s authorized conformance information data within and across networks.
test service providers and having received an
official Declaration of Conformity from ODVA.
Here’s a look at the technology behind every The Physical Layer
DeviceNet product. DeviceNet uses a trunk-line/drop-line topology that
provides separate twisted pair busses for both
signal and power distribution. The possible
Introduction variants of this topology are shown in Figure 1.
DeviceNet is a digital, multi-drop network that Thick or thin cable can be used for either
connects and serves as a communication trunklines or droplines. End-to-end network
network between industrial controllers and I/O length varies with data rate and cable thickness
devices. Each device and/or controller is a node as shown in Table 2.
on the network. DeviceNet is a producer-
consumer network that supports multiple
communication hierarchies and message

©copyright 2004, Open DeviceNet™ Vendor Association, Inc., (ODVA) 1

 Technical Overview

Figure 1: Thick or Thin Cable can be used for either trunklines or droplines

DeviceNet supports both isolated and non-isolated physical layer design of devices. An opto-isolated
design option allows externally powered devices (e.g. AC Drives starters and solenoid valves) to share
the same bus cable. The DeviceNet Specifications contain additional information concerning
component requirements, protection from mis-wiring, and examples.

DATA RATES 125 KBPS 250 KBPS 500 KBPS

Thick Trunk Length 500 m 250 m 100 m
(1,640 ft) (820 ft) (328 ft)
Thin Trunk Length 100 m 100 m 100 m
(328 ft) (328 ft) (328 ft)
Flat Trunk Cable 380 m 200 m 75 m
(1,250 ft) (656 ft) (246 ft)
Maximum Drop Length 6m 6m 6m
(20 ft) (20 ft) (20 ft)
Cumulative Drop Length 156 m 78 m 39 m
(512 ft) (256 ft) (128 ft)

Table 2: The end-to-end network distance varies with data rate and cable thickness.

Several different connector types can be used on DeviceNet (see Figure 2). Both sealed and unsealed
connectors are available. Large (mini-style) and small (micro-style) sizes of pluggable, sealed connectors
are available. For products that do not require sealed connectors, open-style connectors can be used.
Screw or clamp connections can be made directly to the cable if a pluggable connection is not required.
Nodes can be removed or inserted from the network without powering-down the network. A unique
feature of DeviceNet is the ability to add power taps at any point on the network. This makes redundant
power supplies possible. The trunkline current rating is 8 amps.

2 ©copyright 2004, Open DeviceNet™ Vendor Association, Inc., (ODVA)

 Technical Overview

Figure 2: Open and Sealed Connectors are available on DeviceNet

The Data Link Layer it is the same. This allows detection of

The Data Link Layer of DeviceNet is defined by simultaneous transmission. If a node transmitting
the CAN specification and by the implementation a recessive bit receives a dominant bit while
of CAN Controller chips. The CAN specification sending the arbitration field, it stops transmitting.
defines two bus states called dominant (logic 0) The winner of arbitration between all nodes
and recessive (logic 1). Any transmitter can drive transmitting simultaneously is the one with the
the bus to a dominant state. The bus can only be lowest numbered 11-bit identifier. CAN also
in the recessive state when no transmitter is in specifies a data frame format with a 29-bit
the dominant state. This fact comes into play in identifier field that is not used by DeviceNet.
the bus arbitration scheme employed by CAN. The Control Field contains two fixed bits and a
Several frame types are defined by CAN: 4-bit length field. The length may be any number
from 0 to 8 representing the number of bytes in
• data frame • remote frame the Data Field. The 0–8 byte size is ideal for low-
• overload frame • error frame end devices with small amounts of I/O data that
Data is moved on DeviceNet using the data frame. must be exchanged frequently. With eight bytes,
The other frames are either not used on there is enough flexibility for simple devices to
DeviceNet or are for exception handling. The send diagnostic data, or to send a speed
DeviceNet data frame format is shown in Figure 3. reference and acceleration rate to a drive.
DeviceNet also defines a fragmentation protocol
CAN is a carrier sense network. Any node can
that provides a way for nodes to transmit larger
attempt to transmit a message when no other
amounts of data with minimal protocol overhead.
nodes are transmitting. This feature provides
inherent peer-to-peer capability. If two or more The CRC field is a cyclic redundancy check word
CAN nodes try to access the network which is used by CAN controllers to detect frame
simultaneously, a non-destructive, bit-wise errors. It is computed from the bits that come
arbitration mechanism resolves the potential before it. A dominant bit in the ACK slot means
conflict with no loss of data or bandwidth. All at least one receiver besides the transmitter
receivers on a CAN network synchronize to the heard the transmission.
transition from recessive to dominant represented CAN provides very robust error checking and
by a Start of Frame bit. The identifier and the fault confinement employing several types of
RTR (Remote Transmission Request – not used by error detection and fault confinement methods
DeviceNet) bit together form the Arbitration Field. including CRC and automatic retries. These
The Arbitration Field is used to facilitate media methods, which are mostly transparent to the
access priority. When a device transmits, it also application, prevent a faulty node from disrupting
monitors (receives) each bit it sends to make sure the network.

©copyright 2004, Open DeviceNet™ Vendor Association, Inc., (ODVA) 3

 Technical Overview

Figure 3. CAN Data Frame

The Network and Transport Layers would be the destination for Cyclic or Change-of-
DeviceNet requires that a connection with a State messages. Similarly, some connections in
device must first be established in order to either a Client or Server may only produce
exchange information with that device. To messages. These connections would be the
establish a connection, each DeviceNet product source for Cyclic or Changes-of-State messages.
will implement either an Unconnected Message The use of Cyclic and Change-of-State
Manager (UCMM) or a Group 2 Unconnected connections can substantially reduce bandwidth
Port. Both perform their function by reserving requirements. By design, nodes in a DeviceNet
some of the available CAN identifiers. When system are responsible for managing their own
either the UCMM or the Group 2 Unconnected identifiers. These identifiers are interleaved
Port is used to establish an Explicit Messaging (distributed) throughout the entire range. All
Connection, that connection is then used to nodes have a full range of message priorities
move information from one node to the other, or available to them regardless of their Media
to establish additional I/O Connections. Once Access Code Identifier (MAC ID). Through the
I/O connections have been established, I/O data duplicate MAC ID algorithm, the uniqueness of
may be moved among devices on the network. CAN identifiers is guaranteed without the need
At this point, all the protocol of the DeviceNet for a central tool or record for each network.
I/O message is contained within the 11-bit CAN Figure 4 shows the DeviceNet allocations within
identifier. Everything else is data. the 11-bit CAN Identifier.
The 11-bit CAN identifier is used to define the A related issue is detection of duplicate nodes.
connection ID. Uniqueness of connection IDs is Because DeviceNet uses a device address inside
strictly controlled, which is required to take full the CAN Identifier Field, it presents a mechanism
advantage of producer-consumer capabilities. for detecting nodes with duplicate addresses.
DeviceNet divides the 11-bit CAN identifier into Preventing duplicate addresses is better than
four groups. The first three defined groups trying to locate them after they occur —
contain two fields; one 6-bit field for MAC ID and something not taken into account in other CAN-
the other for Message ID. The combined fields based networks. Another key benefit to nodes
define the connection ID. Four messages are managing their identifiers is that a user can add
used for offline communications. and delete nodes and/or add additional peer-to-
Devices may be Clients or Servers or both. peer messages among existing nodes at any time
Clients and Servers may be producers, without having knowledge of the existing set-up.
consumers or both. In a typical Client device, its No centralized record must be located or
connection would produce requests and reconstructed. Since nodes know which IDs are
consume responses. In a typical Server device, already in use, a tool simply has to request an
its connections would consume requests and I/O connection be added between the two
produce responses. DeviceNet provides for devices, specifying priority level, the data path
several variations on this model. Some (class, instance, attribute) and the production
connections in either a Client or a Server may trigger (cyclic, poll, or change-of-state).
only consume messages. These connections

4 ©copyright 2004, Open DeviceNet™ Vendor Association, Inc., (ODVA)

 Technical Overview

Figure 4. DeviceNet Allocations of the 11-Bit CAN identifier field

The Upper Layers: the Common For a given device type, a minimum set of
Industrial Protocol (CIP) common objects will be implemented. The user
benefits from interoperability among devices
DeviceNet uses the Common Industrial Protocol,
regardless of the manufacturer or the device type.
called CIP, for its upper-layers. CIP is strictly
object oriented. Each object has attributes (data) Since CIP-based networks are based on a
and services (commands) and behavior (reaction common application layer, the application data
to events). Two different types of objects are remains the same regardless of which network
defined in the CIP specification: communication hosts the device. The application programmer
objects and application-specific objects. Vendor- doesn’t even need to know to which network a
specific objects can also be defined by product device is connected. Figure 5 provides an
makers for situations where a product requires overview of CIP within the context of DeviceNet
functionality that is not in the specification. and the OSI Model.

Figure 5: The CIP Object Model

©copyright 2004, Open DeviceNet™ Vendor Association, Inc., (ODVA) 5

 Technical Overview

CIP also defines device profiles, which identifies DeviceNet also has standard mechanisms for
the minimum set of objects, configuration vendors to incorporate their own features
options and the I/O data formats for different (objects, attributes, services beyond those
types of devices. Devices that follow one of the defined in the device profile) into their products
standard profiles will have the same I/O data and in addition to the minimum required objects.
configuration options, will respond to all the However, these additional features must be
same commands and will have the same implemented in strict accordance with the
behavior as other devices that follow that same DeviceNet specification in the manner
profile. A subset of the device profiles supported prescribed by the specification.
by CIP and DeviceNet are shown in Table 3. Another important feature that sets CIP-based
networks apart from other network architectures
Device Profile Device Type No. is the ability to originate a message on one CIP-
02hex based network such as DeviceNet, and then pass
AC Drives
it to another CIP-based network such as
Communications Adapter 0Chex
EtherNet/IP with no presentation at the
Contactor 15hex application layer. This seamless bridging and
DC Drives 13hex routing capability sets DeviceNet apart from
1Fhex
other field bus networks. It means that a set of
DC Power Generator objects included in the specification define the
General Purpose Discrete I/O 07hex mechanisms that a bridging device can use to
Generic Device 00hex forward the contents of a message from one
18hex network port to another without acting on the
Human-Machine Interface
contents of that message. When using bridging
Inductive Proximity Switch 05hex
devices that support these objects, the user’s
Limit Switch 04hex only responsibility is to describe the path that a
Mass Flow Controller 1Ahex message must follow. CIP ensures that the
message is handled correctly, independent of the
Motor Overload 03hex
networks involved.
Motor Starter 16hex
CIP is a producer/consumer-based model, rather
Photoelectric Sensor 06hex than a traditional source/destination model.
Pneumatic Valve(s) 1Bhex Producer-Consumer networks provide for more
10hex efficient use of networking bandwidth, A message
Position Controller
is produced onto the network, it is identified, not
Process Control Valve 1Dhex
by its destination address, but by connection ID.
Residual Gas Analyzer 1Ehex Multiple nodes may then consume the data to
Resolver 09hex which this connection ID refers. The result of
this dynamic connection approach provides two
Table 3: Device Types Supported by DeviceNet and CIP clear benefits in the efficiency of the network:
• If a node wants to receive data, it only needs
to ask for it once to consume the data each
time it is produced.
• If a second (third, fourth, etc.) node wants
the same data, all it needs to know is the
connection ID to receive the same data
simultaneously with all other nodes.

6 ©copyright 2004, Open DeviceNet™ Vendor Association, Inc., (ODVA)

 Technical Overview

The Predefined Master/Slave Connection Set The Predefined Master/Slave Connection Set
Fundamentally, DeviceNet employs a peer-to-peer provides connection objects that are almost
messaging model. However, it also provides for a entirely configured at the time the device
simplified communication scheme based on a powers-up. After powering up the network, the
Master/Slave relationship. This predefined only remaining step necessary to begin the flow
connection scheme is known as the Predefined of data is for a “master” device to claim
Master/Slave Connection Set. This connection ownership of this predefined connection set
method simplifies the movement of the I/O within its “slave(s).” Slave devices can produce
messages most often used in control applications. data using one or more of the following message
types, depending on how the device is
Many sensors and actuators are designed to configured and the requirements of the
perform some predetermined function in which application, as shown in Table 4.
the type and amount of data the device will
produce and/or consume is known at power-up.

Type Description of Operation

polled A slave configured for polled I/O will receive “output” data from the master device
in a sequential order that is defined by the master’s scan list. The master’s polling
rate is determined by the number of nodes in the scan list, the DeviceNet baud
rate, the size of messages produced by the master and each node in its scan list
and the internal timing of the master device. For a given system configuration, this
messaging method will provide deterministic behavior. Polled I/O “output” data can
be unicast or multicast.
cyclic A device configured to produce a cyclic I/O message will produce its data at a
precisely defined interval. This type of I/O messaging allows the user to configure
the system to produce data at a rate appropriate for the application. Depending on
the application this can reduce the amount of traffic on the wire and more
efficiently use the available bandwidth.
change-of-state A device configured to produce change-of-state (COS) message will produce data
whenever it changes, or at a base heartbeat rate. This adjustable heartbeat rate
provides a way for the consuming device to know that the producer is still alive
and active. DeviceNet also defines a user-configurable Production Inhibit Time that
limits how often COS messages are produced to prevent nodes from “flooding” the
bandwidth. Users can adjust these parameters to provide optimum bandwidth
utilization in a given application scenario.
Table 4: Slave I/O Message Types in the Predefined Master/Slave Connection Set

©copyright 2004, Open DeviceNet™ Vendor Association, Inc., (ODVA) 7

 Technical Overview

Conformance Testing DeviceNet™ System test verifies that the

ODVA Conformance Testing is designed to product operates in a multi-vendor DeviceNet™
validate that a product complies with relevant system. The product is installed in a 64-node,
aspects of the ODVA specification, from the multi-vendor environment and run in a variety
physical layer through the application layer. of situations specifically designed to identify
Devices that have passed ODVA DeviceNet potential interoperability and system problems.
conformance testing have passed all of the Products must successfully establish explicit
following tests at one of ODVA’s authorized test and I/O connections during various power-up
service providers: sequences, and they must survive the on-line
Control and Information Protocol (CIP) test removal and replacement of other nodes. The
verifies that a product meets requirements of test also confirms that the device will operate
CIP and the additional messaging and under heavy network traffic with scanners
services required for DeviceNet. It tests from multiple manufacturers and that the EDS
conformance at the device profile, file can be used to configure the device.
application layers. ODVA also offers specialized testing:
DeviceNet Electronic Data Sheet (EDS) test DeviceNet Power Supply test verifies that
verifies that the product’s EDS (an ASCII text network power supplies provide the
file supplied by the manufacturer) contains necessary voltage and currents, and operate
the correct grammar and all the required as the specification requires, under a variety
product information, including the device’s of loading conditions.
identity, supported message types, Semiconductor test is another level of testing
configuration parameters and parameter for DeviceNet products used on
enumeration. This file is used by network semiconductor manufacturing tools. Products
configuration software tools to help set up submitted for semiconductor-specific tests
devices on the network. must first pass the standard test suite. This
DeviceNet Physical Layer test verifies that a additional level of testing verifies
DeviceNet product’s physical layer is conformance of connectors, indicators,
designed and operating correctly. For switches, isolation, power, and object
example, it confirms that voltage and current behavior with the ODVA specification
levels remain in allowed ranges during supplement Interface Guidelines for
operation and that the connectors and DeviceNet Devices on Semiconductor
indicators meet ODVA specifications. Manufacturing Tools, including compliance
with CE and SEMI S2.

Once a product passes the appropriate conformance tests, ODVA grants the vendor the right to use its
conformance marks. A list <www.odva.org/10_2/04_products/04_prodtest.htm> of conformance-passed
products also appears on the ODVA web site. Users who wish to specify only products that have passed
conformance tests can find them listed online or identify them by these product marks.

www.odva.org
odva@odva.org

DeviceNet™ and CIP™ are trademarks of ODVA. DeviceNet CONFORMANCE TESTED® is a registered certification mark of
ODVA. EtherNet/IP™ is a trademark used under license by ODVA. ControlNet™ is a trademark of ControlNet International.
PUB00026R1
8 ©copyright 2004, Open DeviceNet™ Vendor Association, Inc., (ODVA)