|
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
DeviceNet
Messages
DeviceNet
has two basic message types: explicit and I/O. The predefined
connection set includes one explicit connection as well
as four I/O connections of different kinds.
Explicit
messages include the path to locate the data of interest.
This consists of the class ID, instance number, and attribute
ID. They also specify an action to be taken (e.g., set
or get). Finally, they include the master’s MAC ID
because a slave must respond only to its master.
With
of all this baggage, explicit messages aren’t efficient.
They are used mainly for initial configuration, although
in theory they could be used for everything. Your device
must support this connection, but others are optional.
In
an I/O poll connection, the master periodically sends
a request saying in effect, "Hey! Send me your data."
It is an efficient exchange because the master doesn’t
need to send any baggage.
When
the slave device sees a message with this connection ID,
it returns a prearranged set of data. On more complex
devices, the master can usually select from various data
sets. If only one I/O connection is supported, it’s
usually this one because it is general purpose.
In
an I/O change-of-state (COS) connection, the device sends
its data when it changes more than a selected amount.
This choice is good for slowly changing data.
The
I/O cyclic connection uses the same connection ID as the
COS connection. The master chooses between the two when
it allocates the connection. With the cyclic connection,
the device sends its data at a selected rate. This choice
works well for rapidly changing data.
In
an I/O bit-strobe connection, the device sends only a
few bits of data in response to the master’s bit-strobe
request. This is a good choice for simple on/off sensors.
With
DeviceNet, no connections exist until they are allocated.
How do you allocate a connection in the first place? I
think the designers of DeviceNet must have struggled with
this.
It
turns out that a special connection always exists—the
unconnected port. The master sends an allocate message
to the unconnected port to allocate connections and specify
which of the predefined connection set it wants to use.
Once you have connections, you can send messages over
them.
Many
CAN controllers have individual mailboxes for incoming
messages. You can assign each connection ID to a different
mailbox. The Intel and Siemens chips have 15 and 16 mailboxes,
respectively, enough for the predefined connection set
with room to spare.
This
makes your program modular from the start. Different messages
come in different boxes.
|
