DeviceNet Explained: CAN, CIP, Power and Wiring

This article is part of the CAN & CANopen family. For the underlying data-link layer details shared across the whole family, see CAN Bus Protocol Explained. For the full protocol family landing with wiring, J1939, and CANopen links, visit the CAN & CANopen category hub.

DeviceNet does something the other CAN-based protocols don't: it puts 24 V power and the data pair in the same cable, so a photoelectric sensor gets its supply and its network from one connector.

That single decision shapes everything else about it — the cable types, the topology limits, the current budgets, the connector families. Understand the power-plus-data architecture and the rest of DeviceNet follows.

This guide covers what DeviceNet is built from, how it uses the CAN identifier, how devices get addresses, and the wiring rules that decide whether a segment works. Verified against IEC 62026-3, the international standard for DeviceNet as a controller-device interface.

The specification in one table

Note the speed-versus-distance trade in row four. It's the same physics as any CAN network — arbitration needs a bit to cross the bus and return within one bit time — but DeviceNet publishes it as fixed pairings rather than a curve. 500 kbit/s buys you 100 m. Need 500 m, run at 125 kbit/s.

Three layers, three sources

DeviceNet is a stack of borrowed parts, and knowing which layer owns what saves a lot of confusion:

CAN provides the data link layer — frames, arbitration, error handling. Everything in the CAN bus protocol guide applies underneath DeviceNet.

CIP, the Common Industrial Protocol, provides the application layer — the object model, services, and device profiles shared with EtherNet/IP and ControlNet. A device's behavior is defined by its CIP objects, not by DeviceNet itself.

DeviceNet supplies the middle: how CIP connections map onto CAN identifiers, how nodes get addresses, and the physical layer with its power distribution.

The practical consequence of CIP being shared: the object model you learn on DeviceNet carries directly to EtherNet/IP. Identity object, message router, connection object — same classes, different transport. Migrating a plant from DeviceNet to EtherNet/IP is far less disruptive than the cable change suggests, because the device semantics don't change.

How DeviceNet uses the CAN identifier

CAN gives you an 11-bit identifier and no opinion about what it means. DeviceNet divides it into four message groups, and this is the heart of the protocol.

Two things fall out of this layout.

Group number is priority. CAN arbitration favors lower identifiers, so Group 1 traffic beats Group 2, which beats Group 3. Time-critical I/O lands in Group 1 by design; configuration and diagnostics sit lower. Priority isn't configured — it's structural.

The MAC ID is inside the identifier. Each node's address occupies bits within the CAN identifier, which is why the node limit is 64 rather than arbitrary: six bits of MAC ID. Explicit messaging and I/O connections can both be established in groups 1, 2, and 3.

A few reserved message IDs are worth recognizing in a capture: Group 2 message ID 6 configures master/slave communications, and message ID 7 detects nodes assigned identical MAC IDs. Group 3 message IDs 5 and 6 carry unconnected explicit messaging — 6 for requests, 5 for responses plus device heartbeat and shutdown messages. Group 3 message ID 7 is invalid.

Addressing and duplicate detection

Every node has a MAC ID — medium access control identifier, the node's link address, 0 to 63. Set by rotary switches, DIP switches, or software depending on the device.

DeviceNet includes a duplicate MAC ID detection protocol that runs at power-up, before a node is allowed to communicate normally. A node announces its intended address; if another node already holds it, the newcomer stops. This is genuinely valuable in the field, because the alternative — two devices answering to the same address — produces symptoms that look like almost anything else.

The practical rule: a device that powers up, flashes an error, and refuses to join the network has very likely found its address already taken. Check for a duplicate before suspecting the hardware.

Two related features round out node management. The device heartbeat lets a node periodically announce it's alive. The device shutdown message lets a node announce it's going offline deliberately, with a code explaining why — which distinguishes a planned shutdown from a failure in the master's logs.

Two kinds of messaging

DeviceNet traffic splits into two categories, and the split maps onto how plants actually use the network.

I/O messaging carries process data. It's connection-based, low overhead, and time-critical — the sensor states and actuator commands the controller needs every scan. Five exchange modes exist: polled (master asks each device in turn), strobed (one multicast request, all devices respond), cyclic (device sends on its own timer), change-of-state (device sends only when data changes), and multicast polled.

Change-of-state is the one worth designing around. On a network of mostly-static discrete devices, it collapses bus traffic dramatically compared with polling, exactly as report-by-exception does on other protocols.

Explicit messaging carries everything else — configuration, diagnostics, parameter reads and writes. Higher overhead, request/response, not time-critical. This is the traffic that flows when an engineering tool talks to a drive.

Since CAN frames carry at most 8 bytes, longer explicit messages use fragmentation and reassembly, splitting across multiple frames with fragment-type bits marking first, middle, and last.

Most master/slave networks use the predefined master/slave connection set — a standard allocation of connections that a master claims with a single allocate service, rather than negotiating each connection individually. Devices that support only this arrangement are called Group 2 only devices, and they're common at the low end of the price range. Devices supporting the UCMM (unconnected message manager) can accept explicit connection requests without pre-allocation, which is what a peer-capable device needs.

Power on the bus

Here's what makes DeviceNet distinctive in the CAN family.

The cable carries two pairs: one differential pair for CAN signalling, one for 24 V DC power, up to 8 A total. Devices that draw their supply from the network are link powered — a photoelectric sensor, a proximity switch, a small I/O block — needing exactly one connector for everything.

That convenience comes with an engineering obligation. Current is limited by the cable, and the maximum available current depends on network length: the longer the run, the lower the current the power pair can deliver, because voltage drop eats the budget. The standard tabulates this per cable type. Two consequences follow:

Power budgeting is a design task. Sum the device currents, check them against the length-derated capacity for your cable, and place power taps where needed. A segment that works on the bench and browns out at full length is a budget problem, not a fault.

Miswiring protection matters. Because the same connector carries power and data, wiring errors are electrically dangerous in a way that a data-only bus isn't. The standard requires devices to survive reverse connection of V+ and V−, and disconnection of V−, without damage.

Cable and connectors

Three cable profiles exist, and choosing among them is a real design decision:

Thick cable — the trunk workhorse. Highest current capacity, longest runs. Thin cable — drop lines and short trunks. More flexible, lower current. Flat cable — for use with insulation-displacement connectors, allowing devices to be tapped onto the trunk without cutting it.

Each has its own specifications for data pair, power pair, topology limits, and length-derated current.

Connectors come in four profiles: open (screw terminals), sealed mini, sealed micro (the M12-style found on most sensors), and flat trunk. Sealed types dominate in washdown and outdoor installations.

Two wiring rules carry over from CAN and are broken just as often. Terminating resistors go at both ends of the trunk, and only there. Drop lines are unterminated stubs, subject to individual and cumulative length limits per cable profile — exceed them and you get reflections that look like intermittent device faults.

The topology is a linear trunk with drops. Not a star, not a ring. Devices attach through device taps on the trunk or at the end of a drop.

Grounding and isolation

The standard is specific here, and getting it wrong causes noise problems that are hard to trace.

The network should be grounded at one point only. Multiple grounds create loops that inject current into the shield and, through it, into the data pair.

Devices come in two flavors: non-isolated, where the device electronics share the network's reference, and isolated, where a barrier separates them. Isolated devices cost more and buy you freedom from ground-potential problems between distant parts of a machine. On a large or electrically noisy installation, that's usually money well spent.

Where DeviceNet sits today

Honest positioning: DeviceNet is a mature protocol in slow decline for new installations, displaced by EtherNet/IP in Rockwell-centric plants. It remains widely installed, well supported, and entirely appropriate where its characteristics fit — device-level networks of sensors and simple actuators, where bus power eliminates a separate supply run and 500 kbit/s is plenty.

The migration story is unusually gentle because of CIP. Moving to EtherNet/IP changes the transport and the cable but preserves the object model, the device profiles, and much of the engineering. It's a transport swap, not a re-architecture.

CIP Safety also runs on DeviceNet, using its own allocation of CAN identifiers, so safety devices can share the network with standard ones.

FAQ

Is DeviceNet the same as CAN? No. DeviceNet uses CAN as its data link layer and adds an application layer (CIP), an addressing scheme, connection management, and a physical layer with bus power. CAN by itself specifies nothing above the data link layer.

How many devices can a DeviceNet network have? 64, because the MAC ID occupies six bits inside the CAN identifier. Addresses run 0 to 63.

What speed and distance can DeviceNet run? 125 kbit/s to 500 m, 250 kbit/s to 250 m, or 500 kbit/s to 100 m. Faster means shorter, for the same arbitration reason as any CAN network.

Can DeviceNet power my sensors? Yes — that's a defining feature. The cable carries 24 V DC up to 8 A alongside the data pair, and link-powered devices draw their supply from it. Available current derates with network length, so budget it during design.

What is a MAC ID? The node's link address, 0 to 63, carried inside the CAN identifier. DeviceNet includes a duplicate MAC ID detection protocol at power-up, so a node whose address is already in use refuses to join rather than causing chaos.

What's the difference between polled and change-of-state? Polled means the master requests data from each device in turn, every scan. Change-of-state means a device transmits only when its data changes. On networks of mostly-static discrete devices, change-of-state cuts bus load substantially.

What is a Group 2 only device? A device that supports only the predefined master/slave connection set, without the unconnected message manager. It works fine with a master, but can't accept arbitrary explicit connection requests the way a UCMM-capable device can.

Is DeviceNet obsolete? No, but it's mature. New Rockwell-centric installations generally choose EtherNet/IP. Existing DeviceNet networks remain supported, and the shared CIP object model makes eventual migration a transport change rather than a redesign.