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

Some Real Messages

Figure 4 shows some real DeviceNet messages based on a typical out-of-the-box slave MAC ID of 63 and a master ID of 1. This situation is typical because it gives the slave device the lowest priority and the master the highest.

For clarity, Figure 4 shows only the connection ID and data fields of the CAN message frame. There are two additional fields. One is a length field that tells the receiver how many bytes of data to expect.

The other field is used for acknowledgment. The node receiving the message sends an ack bit if the message was OK.

CAN messages are variable length. Depending on the number of data bytes sent, a frame can range from 44 to 108 bits.

The first message your device deals with is a duplicate MAC ID check message. Before going online, your device must make sure it has a unique MAC ID.

To do this, your device broadcasts two duplicate MAC ID check messages, 1 s apart, addressed to its own MAC ID. All devices receive this message, but none respond unless your device addresses them!

After sending the duplicate MAC ID check message twice and hearing no response, you can go online.

But since you have no connections yet, you must ignore all messages with two exceptions—a message to your unconnected port to allocate connections, or a duplicate MAC ID check message that contains your MAC ID.

Duplicate MAC ID check messages would be from another device hoping to go online but set to the same ID as yours. Your response to this message prevents the offending device from going online.

When you get a message to your unconnected port it will be the master specifying which connections out of the predefined connection set it wants to allocate. The allocation choice byte contained in this message will have bits set which correspond to the connections it wants.

If you support these connections, allocate them and return a success response. Otherwise return an error and don’t allocate any connections.

Keep track of the master MAC ID that allocated these connections, because from now on this is your master. A message containing a different master MAC ID is ignored.

For each connection allocated, start a timer that deletes the connection if it times out. For the explicit connection, the timer defaults to 10 s. For the I/O poll connection, it defaults to zero and must be set by the master before the connection is used.

The time-out value is controlled by an attribute called the expected packet rate (EPR), which the master can set. Your time-out value, in milliseconds, equals the EPR ? 4. Thus, the EPR for the explicit connection defaults to 2500.

In the I/O message example shown in Figure 4, note that no data, path, or service code is sent with the master’s request. The data set returned with the slave’s response is already specified in the manufacturer’s device profile or electronic datasheet.

More complex devices may have many sets of data the master can choose from. The Master selects the set it wants by changing the slave’s produced connection path.

Because no baggage is involved in the I/O message, it’s an efficient process. A device such as the one modeled in Figure 5 can send its entire sensor and status data in one I/O message. With explicit messaging, many full-length messages would be needed.