DeviceNet : Architecture, Message Format, Error Codes, Working & Its Applications

DeviceNet protocol was at first developed by Allen-Bradley now owned by the brand Rockwell Automation. It was decided to make it an open network by promoting this protocol globally with third-party vendors. Now, this protocol is managed by ODVA Company (Open DeviceNet Vendors Association) allows third-party vendors & develops standards to use the network protocol. DeviceNet is simply layered on top of the Controller Area Network (CAN) technology which was developed by Bosch. Company. The technology adopted by this technology is from ControlNet which is also developed by Allen Bradley. So this is the history of Devicenet. So this article discusses an overview of a Devicenet protocol – working with applications.

What is DeviceNet Protocol?

DeviceNet protocol is one type of network protocol that is used within the automation industry field by interconnecting control devices for exchanging data like PLCs, industrial controllers, sensors, actuators & automation systems from different vendors. This protocol simply uses the normal industrial protocol over a CAN (Controller Area Network) media layer & describes an application layer to cover various device profiles. The main applications of the Devicenet protocol mainly include safety devices, exchange of data & large I/O control networks.

Features

The features of Devicenet include the following.

• DeviceNet protocol simply supports up to 64 nodes including the 2048 highest number of devices.
• The network topology used in this protocol is a bus line or trunk through drop cables for connecting the devices.
• A 121 ohms value terminating resistance is used on any side of the trunk line.
• It uses bridges, repeaters ad gateways & routers.
• It supports different modes like master-slave, peer-to-peer & multi-master to transmit data within the network.
• It carries both the signal & power on a similar cable.
• These protocols can also be connected or removed from the network in power.
• DeviceNet protocol simply supports 8A on the bus due to the system is not secure intrinsically.& high power handling.

Devicenet Architecture

DeviceNet is a communications link used to connect industrial devices like inductive sensors, limit switches, photoelectric, push buttons, indicator lights, barcode readers, motor controllers, and operator interfaces to a network by avoiding complex & costly wiring. So, direct connectivity gives better communication between devices. In the case of wired I/O interfaces, an analysis of the device level is not possible.

DeviceNet protocol simply supports a topology like trunk-line or drop-line so that nodes can be easily connected to the main line or short branches directly. Every DeviceNet network allows them to connect up to 64 nodes wherever a node is utilized by the master “scanner” & node 63 is set aside as the default node by 62 nodes accessible for the devices. But, most industrial controllers allow connecting with several DeviceNet networks by which the no. of nodes that are interconnected can be extended.

Devicenet network protocol architecture is shown below. This network simply follows the OSI model that uses 7 layers from Physical to Application layers. This network is based on the CIP (Common Industrial Protocol) which utilizes the three higher layers of CIP from the beginning whereas the last four layers have been modified to the application of DeviceNet.

The DeviceNet’s “physical layer” mainly includes a combination of nodes, cables, taps & termination resistors within a trunkline–dropline topology.

For the data link layer, this network protocol utilizes the CAN (Controller Area Network) standard that simply handles all the messages between devices & controllers.

The network & transport layers of this protocol will establish a connection by the device through connection IDs mainly for the nodes which include a MAC ID of a device & a Message ID.

The node addresses a valid range for DeviceNet that ranges from 0 to 63 which provides a total of 64 possible connections. Here, the main benefit of the connection ID is that it allows DeviceNet to recognize duplicate addresses by checking the MAC ID & signaling to the operator that it requires to be fixed.

DeviceNet network not only decreases wiring & maintenance costs as it needs less wiring but also permits DeviceNet network-compatible based devices from various manufacturers. This network protocol is based on the Controller Area Network or CAN which is known as communication protocol. It was mainly developed for maximum flexibility between field devices & interoperability between various manufacturers.

This network is organized like a device bus network whose characteristics are byte-level communication and high speed that contains analogical equipment communication & high diagnostic power through the network devices. A DeviceNet network includes up to 64 devices including a single device on every node address that begins from 0 – 63.

There are two standard-type cables are used in this network thick and thin. Thick cable is used for the trunk line whereas the thin cable is used for the dropline. The highest cable length mainly depends on the speed of transmission. These cables normally include four colors of cables like black, red, blue & white. The Black cable is for a 0V power supply, the Red cable is for a +24 V power supply, the blue color cable is for a CAN low signal and the white color cable is for a CAN High signal.

How Does Devicenet Work?

DeviceNet works by using CAN (Controller Area Network) for its data link layer and similar network technology is utilized within automotive vehicles for communication purposes between smart devices. DeviceNet simply supports up to 64 nodes on only the DeviceNet network. This network can include a single Master & up to 63 slaves. So, DeviceNet supports Master/Slave & peer-to-peer communication by using I/O as well as explicit messaging for monitoring, controlling & configuration. This network protocol is utilized in the automation industry for data exchange by communication with control devices. It uses the Common Industrial Protocol or CIP over a CAN media layer to define an application layer for covering a variety of device profiles.

The following diagram shows how the messages are exchanged in between devices within the device net.

In Devicenet, before Input/Output data communication happens between the devices,  the Master device should first connect to slave devices with the connection of explicit message to describe the connection object.

In the above connection, we simply provide a single connection for explicit messages & four I/O connections.

So this protocol mainly depends on the connection method concept where the Master device should connect with the slave device depending on the I/O data & exchanging information command. To set up a master control device, there are simply 4 major steps involved and each step function is explained below.

Add Device to Network

Here, we must provide the MAC ID of the slave device to include in the network.

Configure Connection

For a slave device, you can verify the type of I/O connection & the length of I/O data.

Establish Connection

Once the connection is made then users can begin communicating through slave devices.

Access I/O Data

Once communication is done by slave devices, the I/O data can be accessed through an equivalent read or write function.

Once the explicit connection is made, then the connection lane is utilized for exchanging broad information using one node to the other nodes. After that, users can make the I/O connections within the next step. When I/O connections are made, then I/O data can be simply exchanged in between devices within the DeviceNet network based on the demand of the master device. So, the master device accesses the slave device’s I/O data with one of the four I/O connection techniques. To recover &transmit the I/O data of the slave, the library is not only simple to utilize but also provides many Master functions of DeviceNet.

Devicenet Message Format

DeviceNet protocol simply uses typical, original CAN, especially for its Data Link layer. So this is the fairly least overhead necessary by CAN at the Data Link layer so that DeviceNet will become very efficient while handling messages. Over the Devicenet protocol, the least network bandwidth is utilized for packaging as well as transmitting CIP messages & also least processor overhead is necessary through a device to transmit such messages.

Even though, the specification of CAN defines different types of message formats like data, remote, overload & error. DeviceNet protocol mainly uses just the data frame. So the message format for CAN data frame is given below.

In the above data frame, once a start of frame-bit is transmitted, then all the receivers over a CAN network will coordinate with the transition to the dominant state from the recessive.

Both the Identifier & the RTR (Remote Transmission Request) bit in the frame forms the arbitration field which is simply used to help media access priority. Once a device transmits, then it also checks every bit it transmits at once and receives every transmitted bit to authenticate the transmitted data and to allow direct detection of synchronized transmission.

The CAN Control Field mainly includes 6-bits where the two bits content is fixed and the remaining 4-bits are utilized mainly for a length field to specify the forthcoming Data Field length from 0 to 8 bytes.
The Data Frame of CAN is followed by the CRC (Cyclic Redundancy Check) field to identify frame errors & various frame formatting delimiters.

By using different kinds of error detection as well as fault confinement techniques like CRC & automatic retries, a faulty node can be avoided from disturbing the n/w. CAN provide extremely robust error checking as well as fault confinement capacity.

Tools

The different tools used to analyze DeviceNet protocol includes common network configuration tools like Synergetic’s SyCon, Cutler-Hammer’s NetSolver, Allen-Bradley’s RSNetworX, DeviceNet Detective & CAN traffic monitors or analyzers like Peak’s CAN Explorer & Vector’s Canalyzer.

Error Handling in Devicenet Protocol

Error handling is the procedure of reacting to & recovering from the conditions of error within the program. Since the datalink layer is handled by CAN the error handling related to the detection of faulty node and shutting down the faulty node is as per the CAN network protocol. But,The errors in the Device net mainly occur due to some reasons like when the unit of DeviceNet is not connected properly or the unit of a display may have trouble. To overcome these problems, the following procedure needs to follow.

• Connect the DeviceNet unit properly.
• Separate the cable of DeviceNet.
• For every display unit, the power supply needs to measure.
• The voltage needs to adjust in the range of rated voltage.
• Turn ON the power & verify if the LED of the DeviceNet unit turns ON.
• If the LED of the DeviceNet unit is turned ON, make sure the LED error detail & correct the trouble accordingly.
• If no LEDs on Devicenet are turned ON, then the light may be defective. So need to verify if any connector pins are broken or bent.
• Connect the DeviceNet to the connection through attention.

Devicenet Vs ControlNet

The difference between Devicenet and ControlNet are listed below.

Devicenet Vs Modbus

The difference between Devicenet and Modbus are listed below.

Devicenet Error Codes

The DeviceNet error codes from below 63 numbers and above 63 numbers are listed below. Here < 63 numbers are known as node numbers whereas >63 numbers are known as error codes or status codes. Most error codes apply to single or more devices. So this is shown by flashing the code as well as the node number alternately. If several codes & node numbers must be shown, the display cycles throughout them within node number order.

In the following list, the codes with colors simply describe the meanings

• The green color code will show normal or abnormal conditions which are caused by the action of the user.
• The blue color code shows errors or abnormal conditions.
• The red color code shows severe errors, and probably needs a replacement scanner.

Here a Devicenet error code with the required action is listed below.

Code from 00 to 63 (Green Color): The display shows the address of the scanner.
Code 70 (Blue color): Modify the address of the scanner channel otherwise conflicting address of the device.
Code 71 (Blue color): Scan list needs to reconfigure & eliminate any illegal data.
Code 72 (Blue color): The device needs to check & verify connections.
Code 73 (Blue color): Confirm that the exact device is at this node number and ensure that the device equals the electronic key as arranged within the scan list.
Code 74 (Blue color): Verify the configuration for unacceptable data & network traffic.
Code 75 (Green color): Create & download the scan list.
Code 76 (Green color): Create & download the scan list.
Code 77 (Blue color): Scan list or Reconfigure the device for the proper transmit & receive data sizes.
Code 78 (Blue color): Include or delete the device from the network.
Code 79 (Blue color): Check whether the scanner is connected to a suitable network by at least one other node.
Code 80 (Green color): Locate the RUN bit within the scanner command register and put PLC within the RUN mode.
Code 81 (Green color): Verify the PLC program as well as the command registers of the scanner.
Code 82 (Blue color): Check the configuration of the device.
Code 83 (Blue color): Make sure the scan list entry & verify the configuration of the device
Code 84 (Green color): Initializing communication within the scan list by devices
Code 85 (Blue color): Arrange the device for a lesser data size.
Code 86 (Blue color): Ensure device status & configuration.
Code 87 (Blue color): Verify the connection of the primary scanner & configuration.
Code 88 (Blue color): Check the connections of the scanner.
Code 89 (Blue color): Check arrangement/disable ADR for this device.
Code 90 (Green color): Make sure the PLC program & command register of the scanner
Code 91 (Blue color): Verify the system for failed devices
Code 92 (Blue color): Check whether the drop cable is providing network power toward the port of scanner DeviceNet.
Code 95 (Green color): Do not remove the scanner when the FLASH update is in progress.
Code 97 (Green color): Verify the ladder program & command register of the scanner.
Code 98 & 99 (Red color): Replace or Service your module.
Code E2, E4 & E5 (Red Color): Replace or Return module.
Code E9 (Green Color): Verify command register & power of cycle on SDN to recover.
The scanner is the module that has the display whereas the Device is some other node on the network, normally a slave device within the scan list of the scanner. This can be one more slave-mode personality of the scanner.

Advantages of Devicenet

The DeviceNet protocol advantages include the following.

• These protocols are available at less cost, have high reliability, and have widespread acceptance, network bandwidth is used very efficiently & available power on the network.
• These are capable of collecting large amounts of data without increasing the costs of the project significantly.
• It takes less time to install.
• Not costly as compared to normal point-to-point wiring.
• Sometimes, DeviceNet devices provide more control features as compared to normal or switched devices.
• Most of Devicenet devices provide very helpful diagnostic data that can make systems to troubleshoot very easier & reduces downtime.
• This protocol can be utilized with any PC or PLC or based control systems.

The DeviceNet protocol disadvantages include the following.

• These protocols have maximum cable length.
• They have a limited size of message & limited bandwidth.
• 90 to 95% of all DeviceNet issues mainly occur because of a Cabling issue.
• Less number of devices for each node
• The limited size of the message.
• Cable distance is significantly shorter.

DeviceNet Protocol Applications

The DeviceNet protocol applications include the following.

• The DeviceNet protocol provides connections between different industrial devices like actuators, automation systems, sensors, and also complicated devices without the requirement of intervening
• I/O blocks or modules.
• DeviceNet protocol is used in industrial automation applications.
• DeviceNet network protocol is utilized in the automation industry for interconnecting control devices for exchanging data.
• DeviceNet protocol is used for controlling a motor.
• This protocol is applicable in proximity, simple limit switches & push buttons to control manifolds,
• This is used in complex AC & DC drive applications.

Thus, this is an overview of DeviceNet which is a multi-drop, digital Fieldbus network used to connect several devices from multi-vendors like PLCs, industrial controllers, sensors, actuators, & automation systems by providing a cost-effective network to the users for managing & distributing simple devices by using the architecture. Here is a question for you, what is a protocol?