DeviceNet is a device-level industrial network that appeared in the 1990s and is still found across older automotive, material-handling and packaging plants. It combines the CAN physical layer with the Common Industrial Protocol application layer, and it does something unusual for a fieldbus: it carries both the 24V power that runs simple field devices and the data those devices exchange on the same four-conductor cable. This guide explains how DeviceNet addresses nodes, how it moves I/O data through its four connection types, what its three baud rates trade against distance, and how it relates to the newer EtherNet/IP that a modern SCADA project will usually meet alongside it.
DeviceNet in one line: DeviceNet is a CAN-based fieldbus that runs the Common Industrial Protocol over a single cable which supplies both 24V device power and communications to sensors, valves and drives. Each node has a MAC ID from 0 to 63, exchanges I/O through poll, strobe, change-of-state or cyclic connections, and runs at 125, 250 or 500 kbit/s depending on the segment length. It is the DeviceNet-era predecessor to EtherNet/IP, sharing the same object model.
DeviceNet was built on the Controller Area Network physical layer that the automotive industry had already proven, and it reuses CAN's differential signalling, bit-level arbitration and frame format. On top of that it layers the Common Industrial Protocol, the same object-based application model that EtherNet/IP later adopted, so a DeviceNet device presents its data as attributes of standard objects rather than as raw registers. That shared model is one reason integrators treat DeviceNet and EtherNet/IP as members of one family: a photoeye or a motor starter is described the same way regardless of which wire it sits on.
The characteristic feature of DeviceNet is its round cable, which bundles a twisted signal pair, a twisted 24V power pair, and a shield. The power conductors let simple field devices draw their supply straight from the bus rather than needing a separate feed, which is why a string of proximity sensors or a bank of solenoid valves can be dropped onto a single trunk. Installations distinguish thick cable, used for the trunk and able to carry more current over longer distances, from thin cable, used for the shorter drops out to individual devices. Sizing the power budget across a segment, so that the last device still sees enough voltage, is a normal part of laying out a DeviceNet network.
Because power and data share the cable, a DeviceNet segment behaves as one electrical entity with a single supply, terminating resistors at each end of the trunk, and a defined limit on total current and length. That integration is convenient for wiring but means a fault such as a shorted drop or a missing terminator can disturb the whole segment, so DeviceNet networks are usually laid out and documented with more care around grounding and power distribution than a plain Ethernet run would need.
Every device on a DeviceNet network is given a Media Access Control identifier, the MAC ID, in the range 0 to 63, which makes 64 the maximum node count on a segment. The MAC ID is set on the device, historically with rotary switches or DIP switches and later through software, and it must be unique because it both identifies the node and, through the CAN arbitration mechanism, influences message priority. Duplicate MAC IDs are a classic commissioning fault, and DeviceNet includes a duplicate-address check that a node runs when it powers up before it is allowed onto the bus.
DeviceNet moves cyclic I/O through connections, and it offers several styles suited to different device behaviours. A polled connection has the scanner send a request to a device and receive its data in reply, one device at a time, which is simple and deterministic but grows slower as more devices are added. A bit-strobe connection lets the scanner trigger many simple input devices at once with a single broadcast, which suits banks of discrete sensors. A change-of-state connection has a device report only when its data actually changes, which keeps quiet devices off the wire and reduces traffic. A cyclic connection has a device send its data on a fixed timer regardless of change, which suits values that drift continuously such as an analogue level.
Choosing among poll, bit-strobe, change-of-state and cyclic is really about matching traffic to the device: fast-changing analogue values often use cyclic or change-of-state, dense arrays of on-off inputs use strobe, and general devices default to polled. A DeviceNet scanner is configured with a scan list that records each node's MAC ID, the connection type it uses and the size of its input and output data, and that scan list is effectively the map a SCADA or PLC program relies on to know which bytes belong to which device.
DeviceNet runs at one of three fixed baud rates, and the choice trades speed against distance. At 500 kbit/s a trunk is limited to a short run of roughly a hundred metres, at 250 kbit/s it can reach further, and at 125 kbit/s it stretches to several hundred metres, with cumulative drop lengths scaled accordingly. Every device on a segment must be set to the same baud rate as the scanner, and because the rate is modest by modern standards, a busy DeviceNet segment with many polled nodes can have a scan time long enough to matter for fast machinery. Those limits are part of why the technology has largely stopped being specified for new lines.
For a monitoring project the practical point is that DeviceNet is legacy infrastructure that still runs real production. A plant may have EtherNet/IP as its plant-floor backbone yet keep DeviceNet segments alive under individual machines because rewiring proven equipment is expensive and disruptive. Since both share the Common Industrial Protocol object model, a linking device or a PLC with both a DeviceNet scanner and an Ethernet port can bridge the two, presenting DeviceNet device data upward as EtherNet/IP tags that a supervisory layer can read.
A cloud SCADA platform rarely speaks DeviceNet directly, because DeviceNet is a short-range, wired device bus rather than a routable network. Instead the DeviceNet data reaches the platform after it has been gathered by a controller and exposed through a more transportable protocol, whether that is EtherNet/IP, Modbus TCP or an edge gateway. Understanding that DeviceNet sits at the very bottom of the stack, one hop below the controller, helps a monitoring integrator set expectations: the useful signals are there, but they arrive already mapped into a PLC rather than as an independent network the SCADA host can poll on its own.
No, but they are closely related. Both run the Common Industrial Protocol and describe devices with the same object model, so their application layers are compatible. The difference is the wire: DeviceNet uses the CAN physical layer with power and data on one cable at up to 500 kbit/s, while EtherNet/IP runs CIP over standard Ethernet. A linking device or a dual-port PLC can bridge DeviceNet data onto EtherNet/IP.
A DeviceNet segment supports up to 64 nodes, addressed by MAC IDs from 0 to 63. In practice the scanner and any configuration or interface tools consume some of those addresses, so the usable device count is a little lower. The limit is fixed by the addressing scheme rather than by cable length, which is governed separately by baud rate and power budget.
Thick cable is used for the trunk line; it carries more current and supports longer distances, so it forms the backbone of a segment. Thin cable is used for the shorter drops out to individual devices, where its smaller conductors and lower current capacity are acceptable. Mixing the two lets a network run a robust trunk while keeping the drops flexible and inexpensive.
This page references the protocol specifications published by the organizations below. Editions, product capabilities, and documentation change over time - confirm current requirements and specifications directly with the source.
Last reviewed: July 27, 2026. Merobix is not affiliated with, endorsed by, or sponsored by these organizations; their names are used only to identify the standards and products discussed.
Merobix reads your field devices into a cloud SCADA - the real thing behind these terms, live in days from any browser.