Issue 98, September 1998
Networking with DeviceNet

Start • Sorting Them Out • New Breed • Motivation • Can • Message Reliability • DeviceNet Connections • Device Net Messages • Stringing Messages Together • Some Real Messages • Object Library • Conformance Testing • DeviceNet Standards • References,Sources,PDF

Motivation

Automation-equipment designers are eliminating old-style point-to-point wiring. They want devices from various suppliers to coexist on the same network. Ultimately, they want interchangeability between same-type devices made by different suppliers.

They’re also asking suppliers to make their devices smarter, with better diagnostics. Idiot lights are no longer enough. Diagnostic sensors should provide both alarm and warning levels.

The hope is that the device warns of abnormal levels before it’s too late. If a device does fail, it can easily be swapped out for another, possibly one from a different manufacturer, without powering down the network. When the new device comes up on the network, it tells you what it is, what it can do, and lets you know if it’s OK.

Table 1 compares features of some popular device networks. At this level of comparison, many differences emerge. CAN-based networks have limited range because they are sensitive to time delay on the line. Most other networks use repeaters to extend their range.

With a 500-m range and a 64-node limit, you wouldn’t use DeviceNet to network a large hotel. But, it is an excellent fit in a wide range of applications. The CAN protocol that DeviceNet was built on was originally designed by Bosch for use in autos and trucks. This harsh environment isn’t so different from semiconductor fab tools and other automation equipment.

With a short message length, DeviceNet is well suited for time-sensitive messaging. At 500 kbps, a node doesn’t have to wait more than 0.26 ms to send.