Tech Spotlight: DeviceNet Protocol

rscasny — Thu, 16 Jan 2020 16:11:12 GMT

Current Revision posted to Documents by rscasny on 1/16/2020 4:11:12 PM

DeviceNet was introduced by Allen-Bradley (Rockwell Automation) as a Fieldbus standard addressing the problems related to the wired medium in industrial automation processes. DeviceNet provides reconfiguration flexibility, plug-and-play interoperability, fault diagnosis, advanced failure prevention, high throughput, and repeatability. DeviceNet can withstand noisy industrial environments because of its good electromagnetic immunity and high-performance error detection mechanism. In this article, let us discuss how DeviceNet works.

Overview

DeviceNet is an application layer protocol with the Controller Area Network (CAN) protocol as its backbone. CAN was designed for automotive applications.

It is an open network standard, supported by the Open DeviceNet Vendors Association (ODVA). The application layer of the DeviceNet model offers ease of information exchange across the whole spectrum of DeviceNet devices. By using DeviceNet protocol, programmable controllers can connect to industrial devices, such as actuators or sensors for data exchange.

Features

The key features of DeviceNet are mentioned below:

Network size: it supports Up to 64 nodes. Each node can contain a simple sensor or programmable logic controller (PLC).
Hot Plugging: removal and replacement of devices from the network under power
DeviceNet Network: three-baud rates are available. Distance varies with speed.
Network Devices: can be configured and controlled at the same time.
Transmission Signal: digital square wave with NRZ (Non-Return to Zero) encoding
Bitwise Arbitration: If multiple nodes are trying to access the network simultaneously, a bitwise arbitration resolves the conflict by prioritizing the message without data loss.

Network Architecture

DeviceNet uses Trunk Line and Drop Line topology for communication. The Trunk Line is the network cable between two terminating resistors which connects the nodes and taps. The Trunk Line uses DeviceNet Thick cable, which carries maximum current. Drop Line is the non-terminated network cable, which connects the node to the trunk.

Trunk Line and Drop Line topology reduces troubleshooting time by allowing hot plugging, providing ease of wiring and accessibility through multiple taps. The topology allows signal and power on the same wire. The possible variants of Drop Line topology are shown in Figure 1.

Figure 1: DeviceNet Network Topology

Object-Oriented Approach

DeviceNet is modeled abstractly as a collection of different DeviceNet objects. Each DeviceNet has an Application and Communication object.

Application Object

The application object is responsible for implementing product specific features. It defines the data encapsulated by the device and is specific to the device type and function. For example, in AC motor drive systems, a motor object describes the frequency, motor size, and current rating. In DeviceNet, application objects are predefined for the same device types and placed in the same series.

A series of application objects for a specific device type is known as a device profile. The Device profile helps the user to understand how to switch between two vendor devices with the same device type.

The device vendor can use a super object called an assembly object. The assembly object is a group of attributes of one or more application objects. Usually, the vendor pre-defines the assembly object, but the user can customize it as per their application's need. The assembly object creates a convenient package for data exchange. For example, the vendor of a motion controller with multiple motion controls can define assemblies for each loop. For example, the motion control assembly is configured to send data whenever a state changes, while the second is configured to send data every two seconds regardless of a state change. For these conditions, the user can select the required assembly as per the application need. Vendor-specific objects are not defined in the device class profile. The vendor includes device features in vendor specific objects.

Communication Object

A communication object is mainly concerned with the implementation of DeviceNet protocol messaging. The communication object is divided into four types:

1. Connection Object

It contains the characteristics, which control I/O and explicit messages. These attributes control how often DeviceNet devices create a path for object connection. It connects the data producer and the consumer using a logical connection. DeviceNet is a connection-based network, hence services of each device must be properly logically linked to the data producer or consumer.

2. DeviceNet Object:

The DeviceNet object contains attributes, which identify the port, MAC ID (Address), Vendor ID, Baud Rate, and other physical operating parameters.

3. Identity Object:

This object contains identity attributes for the DeviceNet device. Attributes include the serial number of equipment, vendor ID, manufacturing date, and other identity parameters.

4. Message Router Object:

The message router object is used to route explicit messages and responses between connection objects.

Frame Format

DeviceNet uses the standard CAN data link layer (unmodified) for efficient message handling. It requires less network bandwidth to transmit CIP messages over DeviceNet. Figure 2 shows the CAN Data frame format.

Figure 2. CAN Data Frame Format

When the start of frame is sent, all receivers change their state from recessive (logic 1) to dominant (logic 0). The 11-bit identifier and remote transmission request (RTR) bit together make the arbitration field. This arbitration field provides frame priority. The control field contains the length of the data field. The data packet size is 8 bytes. The cyclic redundancy check (CRC) detects frame error and frame formatting delimiters.

Types of Messaging

In general, three types of messages are exchanged between DeviceNet nodes. These messages use message groups 1, 2 and 3, whereas group 4 is reserved for future modifications.

Figure 3. Message Group Arrangement of DeviceNet

Because of the CSMA/CD and NDBA (Carrier Sense Multiple Access/Collision Detection with Non-Destructive Bitwise Arbitration) bus access method of the CAN protocol, message group 1 has the highest priority for bus access control. The smallest CAN identifier number has top priority. Devices using message group 1 and 3 also arbitrate on message ID. In message group 2, a device with a lower MAC ID wins the arbitration when a bus connection occurs. The DeviceNet data packet has an 11-bit address header. DeviceNet is designed to process many short data packets, to improve network access latency.

In the arbitration scheme, Logic 0 dominates logic 1. If the device transmits a message, it observes the bits on the network. If a device transmits a one and hears a zero, it knows that a higher priority message is sent and it stops transmitting. The device attempts to transmit again when no other is transmitting. This method is known as Carrier Sense. A Carrier sense network can provide peer-to-peer connections.

In a connection object, explicit and I/O connection instances are present. Explicit connection describes the transmission of explicit messages, and I/O connection shows how messaging is managed.

1. Explicit Messages:

They are a Request/ Response type message, between a DeviceNet Master and DeviceNet Slave. Explicit messages use Get and Set attribute service codes for communication. To obtain a device serial number, A Get attribute service request looks like Figure 4.

Figure 4: Get attribute service request

Explicit messaging can also be used for I/O data reading. If the message is greater than 8 bytes, the explicit message can support the fragmentation mechanism. The fragmented message contains only six bytes. When a connection object receives the explicit message, it passes this message to the router object for object class validation. The router opens a DeviceNet package and identifies the target object. After successful validation, the message is passed to the target object for processing. After process completion, the response from the target object is returned to the requester through the router.

2. Peer messages:

They can exchange messages between any two DeviceNet nodes without a master-slave connection. These two nodes or devices must support unconnected messaging. A vendor who manufactures the devices prefers peer communication implementation as a primary choice. In this case, the vendor defines the format and contents of the message.

3. I/O messages:

They send predefined I/O data between the DeviceNet master and slave. As per the network point of view, inputs and outputs are defined. The I/O device creates the input data point and sends it to the scanner, over the network. Similarly, the output is a data point consumed by the I/O device over the DeviceNet network.

Types of DeviceNet I/O messages in a Master/ slave connection include:

Polled: The scanner sends polled messages at a user specific rate. Polled messages are request/reply messages issued for polled connection.
Cyclic: It is scheduled messaging. A DeviceNet slave periodically sends messages to the DeviceNet Master.
Change of State (COS): An event generates COS messages. Additionally, it sends a heartbeat message to show the scanner device that slave devices are still active.

Conclusion

Device-Net Fieldbus is preferred for machine-to-machine communication in a noisy industrial environment, as it provides a secure, uninterrupted, and reliable connection. DeviceNet is commonly used in industries such as Automotive, Food-and-Beverage, Material handling, and Semiconductor fabrication.

Tags: tech connection, controller area network, tech spotlight, devicenet protocol, spotlight, devicenet