|
Issue
98, September 1998
Networking
with DeviceNet
by
Jim Brady
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
Can
There
is much literature on CAN [1], including articles by Brad
Hunting ("The Solution’s in the CAN," INK
58) and Willard Dickerson ("Vehicular Control Multiplexing
with CAN and J1850," INK 69). Here, I’m
only going to cover the most important points.
Network
protocols such as DeviceNet, SDS, and CANopen—all
built on top of CAN—inherit a well-established foundation
for reliable real-time communication. At least five IC
vendors make CAN controllers that handle all the details
of the CAN protocol for you.
What
makes CAN so good for real-time messaging? Short message
length and priority-based collision resolution.
The
latter feature is a major reason for CAN’s popularity.
If a collision occurs, the higher priority message still
gets through intact! In fact, the lower priority colliding
node ends up receiving the higher priority colliding node’s
message.
With
most other protocols, if a collision occurs, no data gets
through, and this can happen over and over. Not cool for
a message to an automobile brake!
CAN
requires nodes to listen before sending. If two or more
nodes decide to send at the same time, it’s the same
time to within a small fraction of a bit time. That means
the messages line up bit-for-bit.
Because
the network line is essentially wire-ORed (see Figure
3), a low bit overrides a high bit. Nodes listen to what
they send, and the node sending the high bit will realize
that it’s receiving a low bit.
| Figure 3—A
DeviceNet line with a one-line driver uses a low
output from the CAN controller to turn both transistors
on while a high output turns both off. It works
like a wire-OR, where any low output dominates
all other nodes’ high outputs.
|
At
that instant, it knows there is a collision and switches
from sending to receiving. The most significant bit of
the Connection ID is sent first, so the message with the
lower-numbered ID wins the bit-wise arbitration and gets
through intact.
For
this to work, nodes at opposite ends of the cable must
have their bits line up to within about half a bit-time.
Thus, the round-trip delay of the cable is limited to
1.0 ?s at the maximum DeviceNet speed of 500 kbps. The
corresponding cable length can be determined by:
where
300 m/?s is velocity of light and 0.72 is the velocity
constant of the DeviceNet cable. That’s why you have
the 100-m limit on cable length at 500 kbps.
|
