Technology
DeviceNet Explained: How It Works, What Breaks It, and When to Migrate
DeviceNet explained for engineering leaders: how the fieldbus works, the media rules that decide its speed, what fails in the field, and when to migrate.
DeviceNet is a device-level fieldbus that connects sensors, actuators, drives, overload relays and block input/output (I/O) to a controller over a single shielded cable that carries both the data and the 24V DC power the devices run on. It was designed in the early 1990s to remove point-to-point wiring from a panel, and at that job it is still good.
If you are reading this, it is probably not because you are specifying DeviceNet. It is because you have inherited it. Somewhere in your plant there is a segment carrying thirty devices that has run without complaint for fifteen years, and a question has come up: a device is no longer available, or a project needs data off that network, or somebody has asked whether it should be replaced. This page is written for that question. It covers how DeviceNet actually works, the design rules that decide what it can do, the failures that show up in the field, where the technology genuinely stands today, and how to think about whether to move.
One conclusion up front, because it contradicts most of what is written about this protocol. DeviceNet is not end of life. The specification is maintained, the conformance test is still being revised, and the mainstream scanner hardware is still listed as an active product. What has ended is new design-in. That distinction changes what you should do about it, and the rest of this page explains why.
Where DeviceNet came from
Controller Area Network (CAN) was developed by Robert Bosch GmbH in the mid-1980s and presented at the Society of Automotive Engineers congress in February 1986. It solved an automotive problem: vehicles were accumulating more wire than could be justified, in an electrically hostile environment, under severe cost pressure. CAN replaced the harness with a two-wire differential bus and pushed the arbitration into silicon.
Allen-Bradley introduced DeviceNet in 1994, taking CAN’s data link layer and adding an industrial application layer on top. The decision that mattered came a year later: in 1995 the technology was transferred to the Open DeviceNet Vendor Association (ODVA), which has maintained it ever since. That is what turned it from a proprietary Allen-Bradley bus into something Omron, Turck, Pepperl+Fuchs, Molex and dozens of others implemented, and it is why a DeviceNet segment in a real plant is usually multi-vendor.
The upper layers are the Common Industrial Protocol (CIP), and this is the detail most write-ups skip even though it is the one that matters most for migration. CIP is the same application layer DeviceNet shares with ControlNet and EtherNet/IP. A CIP object on DeviceNet is the same object on EtherNet/IP. The industry’s move to Ethernet changed the wire and the data link layer; it did not change the application model. That is why a gateway can be transparent to a controller, and it is why the intellectual distance between DeviceNet and EtherNet/IP is much shorter than the physical distance.
DeviceNet is standardised internationally as IEC 62026-3.
How DeviceNet works
The network is a trunkline-dropline topology: a backbone cable with terminators at each end, taps along it, and short drop cables from each tap to a device.
Media, power and the distance rules
Round DeviceNet cable carries five conductors: a red and black twisted pair for 24V DC power, a blue and white twisted pair for signal (white is CAN_H, blue is CAN_L), and a bare drain wire. Flat cable carries four and has no shield. Power rides the same cable as the data, up to 24V DC at 8 A, which is why a photoeye on DeviceNet needs one cable rather than two. In 1994 that was the selling point, and it is still a real advantage.
Three data rates are available, and the cable you have already installed decides which of them you can use.
| Data rate | Thick cable | Flat cable | Thin cable |
|---|---|---|---|
| 125 kbit/s | 500 m (1,640 ft) | 420 m (1,378 ft) | 100 m (328 ft) |
| 250 kbit/s | 250 m (820 ft) | 200 m (656 ft) | 100 m (328 ft) |
| 500 kbit/s | 100 m (328 ft) | 75 m (246 ft) | 100 m (328 ft) |
Read that table carefully, because the figure is not the trunk length. It is the maximum distance between any two devices on the network. In most designs that is the measurement between the two terminating resistors, but where the distance from a tap to the farthest device on its drop is greater than the distance from that tap to the nearest terminator, the drop length has to be counted into the total. A network that passes a trunk-length check can still be out of specification.
There is a second budget, and it is the one that catches people:
| Data rate | Cumulative drop line budget |
|---|---|
| 125 kbit/s | 156 m (512 ft) |
| 250 kbit/s | 78 m (256 ft) |
| 500 kbit/s | 39 m (128 ft) |
The cumulative drop budget is the sum of every drop line in the system, and no individual drop may exceed 6 m (20 ft). Rockwell’s own worked example makes the consequence concrete: thirteen devices on six taps, 42 m of cumulative drop, no single drop over the limit. That design is legal at 250 kbit/s and at 125 kbit/s, and illegal at 500 kbit/s, because 42 m exceeds the 39 m budget.
The practical translation is worth stating plainly. On an existing DeviceNet network, the speed you are allowed to run was decided years ago by whoever laid the cable. If a segment is at 125 kbit/s and somebody wants more bandwidth, the honest first question is not “can we change the rate” but “what is the cumulative drop, and does anyone still have the drawing”.
One 121 ohm terminating resistor goes at each end of the trunk line. Two, no more and no fewer.
Addressing and the message model
Up to 64 nodes sit on a segment, addressed 0 to 63. Addresses are set on rotary or DIP switches, in software, or with a handheld terminal.
DeviceNet is connection-based: a connection is established before any data flows. CAN identifiers are split into a message identifier and a media access control identifier (MAC ID), and nodes manage their own identifiers rather than being assigned them centrally. A duplicate MAC ID algorithm guarantees uniqueness across the network without any central tool or record, which is elegant and has a useful side effect: a duplicated address announces itself immediately instead of causing intermittent corruption that takes a week to find.
Data is produced on one of several triggers, and choosing correctly is most of the bandwidth engineering on this protocol:
| Trigger | Behaviour | When it is the right choice |
|---|---|---|
| Polled | The scanner requests each device in scan-list order and the device answers. Output data is unicast, input data is multicast | Analogue values and anything that must be read every scan regardless of change |
| Strobed | One multicast request solicits a short response from many devices at once | Large numbers of simple devices with very little data each |
| Cyclic | The device produces at a precisely defined interval of its own | Process values where a known sample rate matters more than latency |
| Change-of-state | The device produces only when its data changes | Discrete sensors. Nearly free, and the single biggest bandwidth saving available |
Cyclic and change-of-state connections substantially reduce bandwidth against polling. A DeviceNet network struggling at 125 kbit/s is very often a network that polls everything because polling was the default when it was commissioned.
Both implicit (I/O) messaging and explicit messaging run over a single point of connection. Explicit messaging is how configuration and diagnostics reach a device; implicit messaging is the cyclic data exchange the control logic consumes.
CIP defines device types and device profiles, so two conformant devices of the same type expose the same application interface. Vendors may add vendor-specific objects where a product does something unusual. An Electronic Data Sheet (EDS) file describes a device to the configuration tool. QuickConnect allows a device to be exchanged while the network is running, the canonical case being a robot tool changer.
Implementing it: what deployment actually involves
Designing a DeviceNet segment is a media exercise before it is a software exercise. In order: count the nodes, lay out the trunk and the drops, add up the cumulative drop length, pick the highest data rate the result permits, size the power supply against the load, decide the single ground point, and only then start commissioning devices.
Commissioning is where the time goes. Each device needs a unique address and a matching data rate. The factory default for a DeviceNet device is node 63, at 125 kbit/s, with autobaud enabled. Two new devices out of the box are therefore both node 63, and anyone who has commissioned a segment has met this on their first afternoon.
Configuration is done with a dedicated tool. On the Rockwell side that is RSNetWorx for DeviceNet, which builds the scan list and generates an offline configuration file carrying the I/O mapping. Typical hardware on that platform includes the 1756-DNB scanner for ControlLogix and the 1769-SDN for CompactLogix, with device-side interfaces such as the 22-COMM-D for a PowerFlex drive and the 193-EDN for an E1 Plus overload relay, and a network power supply such as the 1606-XLDNET4. A 193-DNCT handheld gives physical-layer diagnostics and network bandwidth statistics as well as commissioning.
The configuration tool is a quieter obsolescence risk than any of the hardware. It is a separate product from the controller programming environment, with its own licensing and its own expectations of the Windows machine it runs on. A plant that can still open its controller project cannot necessarily still open its DeviceNet configuration, and that is worth checking before it is urgent.
Where it still fits
On a page mostly concerned with leaving, this section has to be honest: an existing, correctly designed DeviceNet segment carrying devices that are still available is not a problem. It is a working asset. Replacing it to reach functional parity is a project with real cost, real commissioning risk and no new output, and “it is old” is not an engineering justification.
DeviceNet is genuinely good at what it was built for. One cable carrying power and data to a large number of simple devices is cheap and tidy. Device-level diagnostics over the network are far better than a hardwired equivalent, where a failed sensor is a silent input. The multi-vendor device catalogue is broad because the specification was opened in 1995. Change-of-state messaging makes discrete sensing almost free in bandwidth terms.
The triggers that should actually start a migration conversation are specific:
- A device on the segment is no longer available and has no drop-in replacement
- The node count has run out, or the cumulative drop budget blocks the data rate a change requires
- The configuration tooling can no longer be run on supportable hardware
- An initiative needs data from those devices somewhere else in the plant, and the segment cannot deliver it
Absent one of those, holding a documented plan is a better answer than starting a project.
What goes wrong
Every failure below is a physical-layer or a design-rule failure. That is the nature of the protocol: the logic rarely lies, the wiring does.
| Symptom | Usual cause | What to check |
|---|---|---|
| A new device does not appear, or the network stops when it is connected | Two devices at node 63, the factory default | Commission each device before connecting it. The duplicate MAC ID algorithm reports it, so read the message |
| Intermittent errors that follow no pattern | Missing, extra, or wrong-value terminator | Exactly two 121 ohm terminators, one at each end of the trunk. Measure across CAN_H and CAN_L with the network unpowered |
| Devices at one end of the network drop out | Voltage drop on the power pair | Measure V- at both extremes. More than 4.65 V of difference between two points on the network causes communication problems. Move a supply toward the heavy loads or add one |
| Whole segment unreliable under load | Supply sagging | V+ to V- below 15 V allows common mode voltage to affect communication. Size the supply against actual load, not node count |
| Noise, and errors that correlate with a large motor starting | More than one earth ground, creating a ground loop | The network is grounded at exactly one location, preferably near the centre, with 25 mm (1 in.) copper braid or 8 AWG wire |
| Network was fine, then a device was added and it degraded | Cumulative drop budget exceeded for the data rate | Re-add every drop in the system. The budget is 156 m at 125 kbit/s, 78 m at 250 kbit/s, 39 m at 500 kbit/s |
| Bandwidth exhausted well below expectation | Everything configured as polled | Move discrete devices to change-of-state. It is usually the cheapest fix available |
The pattern worth internalising: DeviceNet failures are almost never in the scanner and almost always in the media, the power or the addressing. A team that reaches for the controller program first will lose days.
Who builds it and who owns the specification
| Organisation | Role |
|---|---|
| ODVA | Owns and maintains the DeviceNet specification, runs conformance testing, and supports its standardisation in the International Electrotechnical Commission (IEC) |
| Rockwell Automation | Originated the technology as Allen-Bradley in 1994. Scanners, media, and the largest device catalogue in North America |
| Omron | Long-standing multi-vendor implementation on the controller and device side |
| Turck, Pepperl+Fuchs, Molex | Media, connectivity, distribution boxes and device-level products |
| HMS Networks, Pyramid Solutions, Aparian, Real Time Automation, Prosoft Technology | Gateways and linking devices between DeviceNet and Ethernet-based networks |
| CAN in Automation (CiA) | Governs the underlying CAN technology that DeviceNet’s data link layer is built on |
Listed to show the breadth of the ecosystem, not ranked. Joltek is independent of all of them.
Where DeviceNet stands today
This is the part of the page that is most often written badly, so here is the evidence rather than the assertion.
New installation share has collapsed. In the 2026 industrial network market analysis published by HMS Networks, Industrial Ethernet accounted for 79% of newly installed nodes, up from 76% the previous year and from 34% when the survey began in 2015. Fieldbus as a whole fell to 14%. DeviceNet, along with the other CAN-based networks, sits in the 1 to 2 percent range with modest further decline. Effectively nobody is designing new DeviceNet.
And yet the specification is alive. ODVA still owns and maintains it, it remains IEC 62026-3, and ODVA is still issuing revisions of the DeviceNet conformance test, with the current revision cycle running into late 2026. Standards bodies do not fund conformance revisions for dead protocols. The mainstream scanner hardware tells the same story: the 1756-DNB ControlLogix DeviceNet scanner carried Rockwell lifecycle status Active when this page was written.
We looked for a retirement announcement and did not find one. There is no ODVA end-of-life notice for DeviceNet and no vendor announcement retiring the protocol. We state that as the result of a search rather than as a fact about the future.
So what is actually forcing installed bases to move? Three things, none of them a protocol retirement:
- Device-level obsolescence. The scanner is supported. The drive option card, the overload relay, the block I/O and the operator terminal on that segment are each on their own lifecycle and retire independently. A plant does not lose DeviceNet in one event. It loses it one device at a time, and the first unobtainable device is what turns a working network into a project.
- The skills. Commissioning a fieldbus is a distinct discipline: media budgets, terminators, single-point grounding, node commissioning, duplicate address diagnosis. That skill base is not being replenished, because nobody is training on a protocol with one percent of new installations.
- Architecture. A DeviceNet segment is isolated by design, and that isolation used to be a feature. Almost every current plant initiative assumes a device is addressable and its data is reachable. DeviceNet devices are neither.
The honest summary: mature, maintained, and not being designed in. The right posture for an installed base is a documented plan and a spares position, not an emergency.
Migrating off DeviceNet
Two approaches get conflated in vendor material, and they are strategically opposite. The difference is worth a paragraph before any product is chosen.
A protocol gateway or linking device bridges a DeviceNet segment into an Ethernet-based controller. The devices, the media and every one of the constraints above stay exactly as they are. What it buys is a controller upgrade without a device project, which is often precisely the right move: it decouples the two, and it lets a controller migration happen on its own schedule. What it does not buy is any escape from the node limit, the media budget, the tooling dependency or the device obsolescence. It is a way to defer, and deferring is a legitimate engineering decision as long as everyone knows that is what it is. Gateways are available from several vendors, including Rockwell, HMS Networks, Pyramid Solutions, Aparian, Prosoft Technology and Real Time Automation.
Media reuse goes the other way: keep the installed copper, change the protocol, using converters or extenders that carry Ethernet over the existing pair. What it buys is avoiding a wire pull, which in a running plant is genuinely the expensive and disruptive part. What it does not touch is anything on either end of that wire.
Neither one is a migration, and this is the point on which projects are mis-scoped. The moment you replace a device you are into firmware revisions, and the scope does not stop at the device: it reaches the remote I/O, the drives and the operator interfaces, frequently across more than one network, in plants that have not been documented in a decade. A migration presented as a converter swap will be believed by nobody who has run one, and it will be quoted by somebody who has not.
The sequence that works is unglamorous. Establish what is actually on the segment and which of it is still obtainable. Establish whether the configuration tooling still runs. Decide whether the driver is the controller, the devices, or the data, because the answer selects the approach. Then sequence the work so each step leaves the plant in a running state.
Industries
DeviceNet is deployed most heavily in automotive, packaging, food and beverage, and material handling. Those sectors adopted it early for the same reason: large numbers of simple devices spread over a machine or a line, where the wiring saving was immediate and the device-level diagnostics were a genuine step up from hardwired I/O. The underlying CAN technology has an installed base numbering in the billions of nodes across automotive and industrial applications combined.
No credible public figure exists for DeviceNet’s installed node count or its share by sector, and this page does not offer one. Adoption numbers for industrial protocols are rarely published in a form worth citing, and an invented figure would undermine everything else here.
Where Joltek works with DeviceNet
Almost all of our DeviceNet work runs in one direction: getting plants off it. That covers obsolescence assessment on an existing segment, establishing what is still obtainable and what is not, deciding between a gateway and a full device-level migration, and sequencing the work so the line keeps running through it.
What we bring to it is the scope discipline. Our position, stated to vendors and clients alike, is that a DeviceNet migration is not a converter swap. It is a legacy modernization with firmware, drive, operator interface and network architecture consequences, usually in a plant where the documentation stopped being accurate some years ago. Underselling that is how these projects get approved at the wrong number and then run long.
What we do not do: we do not design new DeviceNet networks, and we would push back on anyone proposing one. We are also not a media supplier or a hardware reseller. Where a migration path involves particular converters, gateways or media, we specify against the requirement and the plant’s existing standards, and any commercial relationship we hold is disclosed on our partners page.
If you are holding a DeviceNet installed base and trying to work out whether it is a problem this year or in five, that assessment is the kind of work we do under systems modernization and risk management.
Related reading
- OT networks, the layer this sits in, and how device-level networks relate to the plant network above them
- EtherNet/IP and CIP, the application layer DeviceNet shares with its most common migration target
- Stratix and network segmentation, which is where the architecture question lands once devices become addressable
- Rockwell Automation, the platform most of the North American DeviceNet installed base sits behind
- Systems integration, for the delivery side of a migration
All product names, logos and brands are the property of their respective owners. Use of these names does not imply any affiliation with, endorsement by, or partnership with the manufacturer. Joltek is an independent consultancy; commercial relationships, where they exist, are disclosed on our Partners page.