Overview¶
DeviceNet™ is a digital, multi-drop network that connects and serves as a Communication Module network between industrial controllers and I/O devices. Each device and/or controller is a node on the network. DeviceNet™ is a producer-consumer network that supports multiple Communication Module hierarchies and message prioritization.
DeviceNet™ systems can be configured to operate in a master-slave or a distributed control architecture using peer-to-peer Communication Module. DeviceNet™ systems offer a single point of connection for configuration and control by supporting both I/O and explicit messaging. DeviceNet™ also has the unique feature of having power on the network. This allows devices with limited power requirements to be powered directly from the network, reducing connection points and physical size.
DeviceNet™ follows the Open Systems Interconnection (OSI) model, an ISO standard for network Communication Modules that is hierarchical. Networks that follow this model define all necessary functions from the physical implementation up to the protocol and methodology to communicate control and information data within and across networks.
| Network size | Up to 64 nodes |
|---|---|
| Network length | Selectable end-to-end network distance varies with speed. 125 kbit/s 500 m (1640 ft) 250 kbit/s 250 m (820 ft) 500 kbit/s 100 m (328 ft) |
| Data packets | 0-8 bytes |
| Bus topology | Linear (trunk line/drop line); power and signal on the same network cable |
| Bus addressing | Peer-to-peer with Multi-Cast (one-to-many); Multi-Master and Multi-Slave special case; polled of change-of-state (exception-based) |
| System features | Selectable end-to-end network distance varies with speed |
Fundamental Properties and Fields of Application
DeviceNet™ is mainly used to transfer process data between central controller modules (such as PLC or PC) and decentralized peripheral modules such as I/O modules, drives and valves. To perform this, DeviceNetä uses the physics and data transport mechanisms of the Controller Area Network (CAN). Communication is performed message-oriented. The subscribers exchange data cyclically, change-controlled or event-controlled via the logical interconnections specified during configuration. DeviceNet supports transfer rates of 125 kbaud, 250 kbaud and 500 kbaud.
Each of the up to 64 subscribers in a DeviceNet™ network has an own MAC ID (Media Access Control Identifier, bus address). The Duplicate MAC ID test algorithm, which is executed when booting the system, guarantees that each MAC ID exists only once in the network. DeviceNet™ does not use the conventional master/slave principle. Each subscriber is generally authorized for transmission. As soon as a module reaches a state that activates a configured connection (e.g. changed input value), the module tries to transmit a corresponding telegram via the bus. In this case, it may happen that several subscribers try to send a telegram at the same time. Telegram collisions are detected and removed by the CSMA/CA procedure (Carrier Sense Multiple Access/Collision Avoidance). Each telegram contains a priority identification. The lower this value is, the higher is the priority of the message. The bus address of the sender is part of this priority identification. Due to this, subscribers with a low MAC ID have a higher priority than subscribers with higher addresses when assigning the bus accesses. If a transmission attempt of a subscriber is interrupted by a telegram with a higher priority, the interrupted subscriber disconnects from the bus and then repeats its transmission attempt after the transmission of the high-priority telegram is finished. If a default number of failed transmit attempts is exceeded, the DeviceNet™ module changes to the fault state. Due to this, normally as low as possible MAC IDs are assigned to DeviceNet™ masters.
DeviceNet™ distinguishes three device types: Clients, servers and devices which combine both types of functionality. In principle, all device types can receive (consume) or send (produce) data or perform both. A client (master) typically sends data in form of a request and receives data as an answer to this request. Servers (slaves) typically consume requests and then produce the answers. Depending on the configured connection, slaves are also able to send data via the bus without any previous request by a master. Some devices (clients and servers) can only consume messages (pure output devices) or produce messages (pure input devices).
With DeviceNet™, mono master as well as multi master and multi client systems can be realized. In theory each master can access all slaves (servers). The actually realized communication connections are specified during configuration prior to commissioning. Configuration of the connections is done in masters. When booting the system, the master establishes the corresponding connections, i.e. it informs the slaves how to perform communication between the slaves and the master. Pure servers cannot initiate connections, pure clients cannot receive requests. Communication connections are only possible between a master (client) and several slaves (servers) and devices which support both types of functionality. Mixed devices can communicate with other mixed devices as well as with pure servers.
Figure: Communication connections
Standardization
BOSCH CAN Specification - Version 2.0, Part A
ISO 11898
ODVA DeviceNet Specification Release 2.0, Errata 1 & 2
Terms, Definitions and Abbreviations
| ACK | Acknowledged Exchange |
| ODVA | Open DeviceNet Vendor Association |
| CAN | Controller Area Network |
| COS | Change Of State |
| EDS | Electronic Data Sheet |
| MAC ID | Media Access Control Identifier, bus address |
| Trunk Line | Main strand of the bus |
| Drop Line | Branch line |
| UCMM | Unconnected Message Manager |