A DeviceNet node will have a transceiver chip and the CAN protocol controller. Together they format messages for transmission and reception by the node, shown here as the module controller.
Select figure to enlarge.

When setting up a drive, everyone knows an "object" is something you want to accelerate to a particular velocity in the shortest time possible. But what is an "object" when you're connecting a drive to an industrial network? Here's a clue: it doesn't accelerate.

There are many terms in the world of communication networks that are probably unfamiliar to motion engineers - terms like "class" and "attribute," and understanding them will make it easier to link drives to networks. This introduction to networking terminology looks specifically at installing DeviceNet into a motion system, as most drives now offer an interface to this popular bus.

Getting physical

In networking, the hardware is referred to as the "physical layer." In DeviceNet, it consists of an integrated- circuit transceiver device based on the Controller Area Network (CAN) bus and the transmission media of cables, connectors, and junction boxes.

The transceiver is a balanced differential- voltage driver and receiver package that employs twisted pair communications similar to the RS- 485 systems. Its outputs connect directly to the DeviceNet cable.

The physical layer can be configured as a "trunk and drop line" where the cable is laid as a backbone (trunk) with additional cables branching (drops) from it to the individual nodes, or connected devices. The physical layer addresses up to 64 nodes. It's structured so that you can remove any node without shutting down the network. The cable wire, a twisted pair signal conductor and braided shield with drain, houses both signal and 24 Vdc power conductors. The 24-V conductors can power some low-power devices directly.

The physical layer also offers selectable data rates of 125, 250, and 500 kbaud. Cable lengths are a function of data rates, so the higher the rate, the shorter the cable.

Proper protocol

DeviceNet's foundation is a network protocol that's also based on CAN. CAN was developed in Europe by Bosch to provide an internal communications network for automobiles. In this application, it requires a high level of error detection, low latency (response) times, and a high degree of determinism or confidence that messages are transmitted and received at specific times.

Select figure to enlarge.

Its success has resulted in a readily available supply of low-cost integrated circuit products. Intel, Motorola, Philips, and Siemens all manufacture CAN bus interface chips as well as microprocessors with integral CAN controller modules.

The protocol controller accepts data from a device's main processor and formats it for transmission on the bus. It also receives information from the bus and converts it to data for use by the main processor.

The protocol and transceivers allow non-destructive message arbitration. In other words, if two devices send a message at the same time, the higher priority message remains intact and continues to its destination. This conflict-resolution scheme is different from many networks where both messages would be lost and the transmitting devices would need to re-issue them.

A node's main processor must format information sent to and received from the protocol controller in a manner that conforms with DeviceNet specifications. This is the job of the Application Layer.

Loose ends

There are several components that make up a typical DeviceNet system, including a PLC or PC, a scanner, cabling, and the various nodes on the network. The scanner serves as the interface between a PLC or PC and the network. It is located in the PLC as a separate module, and in the PC as an option board. We'll assume that a PLC is the system controller for the following discussions.

Each device connected to the network has its own address. The address is referred to as a media access control identifier or MAC ID, and goes from 0 to 63. These identifiers are usually set by a switch on the devices.

The scanner module acts as a buffer between the main PLC processor and network. It holds records of information moving through the network in the form of data tables. The information includes the status of discrete inputs and outputs, as well as large data blocks. These tables are continuously updated at a rate selected during initial network setup, typically about 10 msec. Tables for large blocks of data are only updated when a PLC initiates a request for data.

Continue on page 2