Devicenet protocol pdf

There is also a shield wire used in the grounding process. The cable that you choose to fit your application will be based mainly on distance because there are specific limits to the lengths that will allow maximum data rates. DeviceNet data rates are , , or Kilobits per second. The longer the length needed will result in a slower data rate and vice versa.

Since there are no predetermined cord lengths in DeviceNet, you can put connections to the Flat cable anywhere on the line, making this choice great for device placement. The drop lines connect the devices to the trunkline and the data rate you choose determines the total drop line length allowed. The biggest restriction for a dropline is that the maximum cable distance from any device to the trunkline is 20 feet.

The maximum total drop length for each data rate is feet at Kilobits per second, feet at Kilobits per second and feet at Kilobits per second. Once again showing that at higher data rates you get shorter distances your network can reach, and lower data rates get you farther reaching capabilities. The DeviceNet trunkline requires a Ohms, 1 percent, 0. The terminating resistors reduce electrical noise and without them, in their correct place, the DeviceNet will not work properly. This choice will impact the total drop length calculation because the direct connections are considered zero drops while branching or daisy chaining adds to that calculation.

These connections were specifically designed to allow devices to be replaced without disrupting the network. DeviceNet uses Electronic Data Sheets EDS that are simple text files that contain all the information to identify a device and assist in commissioning them onto the network. The advantages of DeviceNet are low cost, widespread acceptance, high reliability, efficient use of network bandwidth and power available on the network. The disadvantages of DeviceNet are limited bandwidth, limited message size, and maximum cable length.

It is stated over and over in many documents that 90 percent to 95 percent of all DeviceNet problems are one of two things;. Thanks again for reading. This is my personal experience as someone who searched for a job in this field and as an employer who reviews resumes and interviews candidates for a variety of projects.

It would be difficult to walk through any industrial or food processing plant or manufacturing facility without seeing a pressure gauge of some Learn how to program PLCs, install and wire industrial devices, and at the same time purchase them online. What is Devicenet? In this video and article, we will take a journey through the automation world of DeviceNet protocols. DeviceNet is an application-level protocol used in the automation environment.

DeviceNet Physical Media System. DeviceNet Cables. They are: 1. Thick Round 2. Thin Round 3. Class 1 Round 4. KwikLink Flat 5. KwikLink Lite Flat Which DeviceNet cable you choose is determined by the distances and physical limitations of your application.

These distances are measured by two variables: 1. Trunkline distance 2. For most DeviceNet Messaging, messaging between a Master Device and a Slave device, the Connection IDs are predefined enabling low resource devices to optimize processing of these messages. Using the filters provided in a lot of CAN controllers, these messages are easily identified and processed while all other messages are quickly discarded. For all but a few types of connections, two connection IDs are allocated.

One, the produced Connection ID is allocated for the message transmitted by the device. The Connection IDs are an integral part of DeviceNet messaging and are a part of the message prioritization scheme. In some networks with certain types of messaging schemes using lower Mac ID addresses for higher priority devices is a valid optimization strategy.

This virtual port provides a way for a device to send a few predefined messages to a DeviceNet device without first making a connection. The predefined messages are limited to creating and deleting other connections. This connection is designed for very unsophisticated, low resource devices.

More sophisticated devices also implement the Unconnected Message Port. For these devices this port can be used to create Explicit Connections on Connection Groups 1 or 3, connection groups that are used to transfer Explicit Message Requests. Connected Messages are messages produced and consumed across a connection between two devices. Connected messages can also be messages transferred at some specific data rate cyclic messages , on response to a poll poll response messages or on a Change-Of-State COS messages.

The data may be public, predefined assemblies of data or proprietary data specific to a particular vendor proprietary peer message. The fact that two devices are connected does not imply anything about the data being transferred over the connection. DeviceNet devices can be classified as Master or Slave devices. Master devices are devices that gather Input data from multiple slave devices and distribute Output data to the slave devices.

Master devices are also referred to as Scanners and Client devices while slaves can be referred to as Servers. The direction of data transfer is always discussed in terms of the DeviceNet network. Data that is moved from the network into a device is Output data. Data that is moved from a device to the DeviceNet network is Input data. DeviceNet now includes a connection set for devices in the Communication Faulted State.

A device in the Communication Faulted state is unable to transfer any data or perform any application operations until the fault is cleared. The fault is typically cleared by manually re-addressing the network so that no devices exist with duplicate addresses.

If many devices have the identical address, manually re-addressing the network is very time consuming and difficult.

Either the switches on the device must be individually and manually changed or all devices must be removed from the network.

Once all devices are removed each software addressable device can be added to the network and re-addressed one at a time by a configuration tool.

This time consuming and tedious procedure is what the Offline Connection Set messaging is designed to address. Using the Offline connection set a configuration tool can connect to a Communication Faulted device, change its address and then reset it. Since many Communication Faulted devices may be sharing an address, the configuration tool uses the vendor serial number to identify a specific device on the network. By flashing the LEDs of that device in a specific patter, the tool can identify the faulted device to the user who then can assign an address to that device.

There are three kinds of messages that can be transmitted between DeviceNet nodes. Peer messages are unformatted messages between any two nodes.

Peer Messaging in DeviceNet is a widely misunderstood concept. Though Peer Messaging is supported there is no practical way for devices manufactured by different vendors to communicate over peer communication channels. Peer messaging is simply the exchange of messages from one DeviceNet device to another over any non-Master Slave connection. If two devices both support unconnected messaging and one of the devices can issue an unconnected message a peer communication channel can be created between the two devices.

Unfortunately creation of the peer communication channel does not imply that the two devices can exchange meaningful data. If a DeviceNet temperature controller sends a temperature over a peer connection to a display, there is no way for the display to decipher the data. The temperature may be in Celsius or Fahrenheit. It may be 16 bits or 32 bits, scaled or un-scaled. Most implementations of Peer communications are used by devices manufactured by the same vendor.

The vendor defines the format and contents of the message so that each device can understand the contents of the message. Using 2 or more scanners situated all around a target the barcode device which reads the barcode sends a message to the other scanners indicating that it has the barcode and that they can discontinue scanning. The Service Code field in the explicit message identifies the requested service with the remainder of the message containing any data required to execute the service.

Explicit messages are used by all devices including configuration tools. Traditionally Inputs and Outputs are referenced from the point of view of the network. The Input Assembly Object identifies the data produced by the Device. Attribute three of each Input Assembly object is the attribute containing the data to produce.

Attribute three is usually a collection of data from one or more application objects. Figure 2 is an example of the Assemblies that you might find in a simple flow meter.

Output Assembly objects identify data consumed by the device. Attribute three of each Output Assembly identifies the specific data consumed by the device. Attribute three of each Output Assembly is usually a collection of data consumed by the device. The data consumed is destined for one or more application objects as it is received.

A device can have multiple Input and Output Assemblies. For example a barcode reader device may have some set of discrete inputs and outputs. This provides the ultimate flexibility for the end user. Figure 2 is an example of a device with more than one assembly.

In this example, the user can choose from two assemblies for a simple Flow Meter. In the Connection object there are a minimum of two connection instances. The Explicit connection describes the how explicit messages are transferred. There are a number of different ways to specify the connection path most of which require more explanation than can be provided in this document.

To change the Connection path a user can use an Explicit message to set this path directly or in many cases the vendor of the device provides a selector attribute in one of the application objects to more easily set the path.

If a device only supports direct management of the Connection Path attribute the user may have to consult the device documentation or the DeviceNet specification to correctly specify the path. The multiple messages are transmitted with no special encoding or sequence number. Service Code data associated with these messages includes:. The Router validates the Object Class. If the Explicit Message contains an invalid Class, the router rejects the message and returns an error code to the requester.

If the Router validates the Object Class it passes it to the target Object for processing. The response from the target object is returned to the requester through the router. Note that this is only the network view of the device operation and may or may not be how the device is implemented. An Explicit Message connection may support a fragmentation mechanism for messages greater than 8 bytes.

Fragmented explicit Messages contain only six bytes of data. Two header bytes to manage the fragmentation are added to every message. One header byte indicates the fragmented message position First, Last, Middle in the message sequence while the second byte contains a sequence number. The receiver Master or Slave device must transmit a message indicating acceptance of the fragmented message before the next message in the sequence is transmitted.

DeviceNet devices are not required to support Explicit Message fragmentation. In fact most devices do not as Explicit Message fragmentation and the required acknowledgement handing requires a tremendous amount of device resources. A little know fact is that most DeviceNet device names an ASCII string are eight or less bytes in length to avoid support of explicit message fragmentation since longer product names would be transferred to the Master as a fragmented message sequence.

There are only two requirements for successfully placing a new device on a network. One, the baud rate of the device much match the baud rate of all other devices on the network and two, the device address must not conflict with an address of another device.

The baud rate limits the length of the network. Very simply, CAN networks require every device to listen to its own bits as they are transmitted and to set the acknowledge bit in each and every message transmitted on the network.

The implementation of this latter requirement dictates the maximum network length for each baud rate:. Identifying the current baud rate of a device can be a challenge. Unless a device is configured using dipswitches and the baud rate can be discerned from the switches, there is no way to know what the baud rate might be. One of the reasons that a device may not connect is a baud rate that is different than the network baud rate. An integer address is assigned to every DeviceNet device on a network.

This integer is the device address or MacID. There are a maximum of 64 nodes on a DeviceNet network. These nodes occupy MacIDs addresses 0 to 63 and can be set using switches or using a DeviceNet configuration tool. No two devices can occupy the same DeviceNet Address. At power on each DeviceNet device sends out a message requesting access to the network.

Part of this message is the unique device serial number. If more than one devic from the same vendor all with the same vendor id power on and attempt to access the network at the identical instant the device with the lowest DeviceNet serial number is successful. All the other devices fault. This sequence is explained in more detail in the next section. The DeviceNet protocol requires that devices transitioning from the offline to on-line state follow a very specific message sequence with specific timing.

This sequence relies on the Duplicate MacID request message. This ensures that no two Duplicate MacID request messages can have the same contents. If no response is received after the second, one second delay, the device can officially transition to the online state. There are other more subtle requirements for DeviceNet devices.

For example if a device in the online state ever receives a Duplicate MacID response message it must immediately transition to the offline state. A message that is directly opposite the Duplicate MacID request message is the device shutdown message.

This message broadcasts the fact that a device is transitioning from the online state to the offline or non-existent state. This is an optional message that can be used by a device to signal a fault condition, remote command or some other reason for taking itself off the network. Another infrequently used message is the Device Heartbeat message. A device can support any one or all of the device types simultaneously. The allocation process, described later in this document, is a set of handshaking messages in which the Master device requests control of the slave and then configures the slave to transfer a particular set of data at a data rate specified by the Master.

If the slave accepts ownership it replies in the affirmative and creates the connections requested by the Master Device in the request message. A Slave may deny the allocation request from the Master Device. Slaves may deny a request if they are already allocated to another Master or if the Master device requests an unsupported connection type.

For example if the Master requests a cyclic connection and the DeviceNet Slave only supports polled connections the allocation request is denied. If the Master fails to scan at this rate, the Slave device enters a Timed-Out state and must be explicitly reactivated by the Master Device. The Produced and Consumed connection paths are the paths to the application objects where data is respectively generated or stored. Generally these paths refer to one of the assemblies supported by the Slave device.

Scanning can begin once the Slave device is fully configured. During scanning the Master device produces and consumes Slave data. Slave Devices, sometimes known as servers, are devices that receive and transmit application specific data to and from a Master device. Slave devices by definition implement the Predefined Master Slave Connection Set described in the previous section.

The Slave device can then implement whatever functionality is required of the device when its master is not in run mode. Master devices such as Configuration tools often allocate the Predefined Connection Set of a Slave device requesting only the Explicit Message request connection.

These devices typically allocate the EM connection, get or set a particular attribute and then release the connection set. If these devices are currently allocated by another Master device the Master owning the DeviceNet slave mimics the messages of an unconnected slave device but only accepts the Explicit Message connection. Messages for the owned slave are received by this Master and sent to the slave.

The response from the slave is received and relayed to the original requestor, just as if the original Master device was communicating with the Slave directly. In this fashion a device, like a configuration tool, can get or set an attribute of a DeviceNet slave even if a Master already owns it device.

DeviceNet devices are configured using external hardware or software configuration tools. External hardware can include rotary switches, thumbwheels, dipswitches and other fixed input devices.

Software configuration tools access the internal configuration of the device over the DeviceNet network or other communication port. Generic tools that can configure any DeviceNet device use the DeviceNet network.

Vendor specific tools that configure just the devices of that vendor may either use the DeviceNet network or some other communication port on a device. Some end users prefer configuration using switches. Their philosophy is that a device can be easily replaced if all it takes is to set switches and connect the replacement devices.

Other end users prefer software configuration. These users view switches as a potential source of device failure. DeviceNet requires termination resistors at each end of a DeviceNet trunk line. The DeviceNet specification expressly recommends that these termination resistors not be included within a device.