DeviceNet Messaging Scheme is responsible for all data transfers in the protocol. It partitions the 11-bit CAN identifiers into 4 main message groups, i.c. Message Group 1, Group 2, Group 3 and Group 4. These message groups have differing priority in bus arbitration, where Group I Messages command
By S B . Khoh Page 3-9
Chapter 3 - The Dev ic eNet Fieldbus
the highest priority. (In CAN, the lower the Identifier number, the higher the priority of the message.) Table 3-2 shows the breakdown of the message groups in the CAN identifier field. The 11-bit CAN Identifiers are referred to in later sections as the Connection ID (CID).
Table 3-2 The DeviceNet Message Groups [62)
1 1-bit C A N Id en tifie rs DeviceNet protocol uses the CAN data field to define the protocol information in certain instances. This further expands the messaging capability of the DeviceNet protocol. Figure 3-3 shows the DeviceNet messaging scheme responsible for data transfers.
Figure 3-3 The summary of DeviceNet Messages
liyS.li. Khoh Page 3-10
Chapter 3 - The DeviceNet Fieldbus
The I/O messages of DeviceNet utilise Message Group 1 for highest priority bus access and are suitable for real-time communication. Explicit Messages occupy Message Group 2 for point-to-point communication, and are more suited for application with fewer time critical messages. From Table 3-2, it can be seen that I/O messages (Group 1) have a higher priority than those explicit messages (Group 2). This corresponds with the CAN protocol where the lower the CAN identifier, the higher the priority for bus arbitration.
3.3.1 Explicit Messaging
All communications in DeviceNet starts with the Explicit Messaging. As mentioned earlier, the explicit message o f DeviceNet uses the CAN data field Explicit Messaging Connection Response message consists of six data bytes.
Explicit Message with a Message Body o f more than seven bytes will be transmitted under the Fragm entation Protocol, which will be discussed in Section 3.3.3.
Hy S B. Khoh Page 3 - 1
Chapter 3 - The DeviceNet Fieldbus Open Explicit Messaging Connection Request
Open Explicit Messaging Connection Response
Figure 3-4 Open Explicit Messaging Connection Request/Response Message
[62|
3.3.2 I/O Messaging
Explicit Messaging forms the fundamental communication mechanism of DeviceNet. Explicit Messaging is responsible for establishing the logical connections between nodes on the network. Having established the logical link between the producer and the consumer of the data, the devices can implicitly use the I/O messaging for very fast data exchange. Therefore, I/O messages are only useful to those nodes who have prior knowledge on the Protocol Data Unit (PDU)’s data. To a casual observer such as a bus analyser, the I/O messages will be meaningless, unless this casual observer is present during the
lly S I I Khoh Page 3-12
Chapter 3 - The DeviceNet Fieldbus
establishment process o f the logical connections. PDU using the I/O Messaging scheme does not have any protocol information encoded in the CAN data field, with the exception of the Fragmented I/O Message.
3.3.3 Fragmentation Protocol
It is possible to transmit information which consists of more than 8 data bytes per PDU in DeviceNet using the Fragmentation Protocol. Fragmentation protocol supports both the I/O Messaging and Explicit Messaging. The Fragmentation protocol adds a byte of overhead into the existing data format of both I/O and Explicit Messages. As a result, Fragmented I/O messages only transfer 7 bytes of data in one PDU, whilst the Message Body o f Fragmented Explicit Message is reduced to 6 bytes per PDU.
Both I/O and Explicit Fragmentation Protocol Messages format are shown in Figure 3-5. The shaded areas are responsible for Fragmentation Protocol. Notice that the IIO Fragmentation Protocol uses a data byte less than the Explicit Fragmentation Protocol. The Fragment Type indicates whether the PDU is the first fragment (0), middle fragment (1) or last fragment (2). The first fragment must have the value 0 or 3F hex (111111 binary) in the fragment count field in order to be valid. Other successive PDUs that follow the first fragment must have the middle fragment indicated in the fragment type field. The fragment count will be incremented according to the following formulae.
IIy S.ll Khali Page 3-13
Chapter 3 - The DeviceNet Fieldbus
Figure 3-5 The Fragmentation Protocol Message Format [62]
Fragment Count = (Fragment Count + 1) mod 64
When the transmitter reaches its last fragmented PDU, it will indicate to the receiver by putting the value 2 in the fragment type Field to indicate that it’s the last fragment. In the Explicit Fragmented Messaging scenario, the receiver must acknowledge the reception o f the each fragment by transmitting a value 3 in the fragm ent type field. The DeviceNet Specification, however, does not define whether the receiver needs to echo back the fragment count
fly S B. Khoh Page 3-14
Chapter 3 - The DeviceNet Fieldbus
and data bytes to the transmitter, or just acknowledge with a value 3 in the fragment type field.
With fragmentation protocol, the maximum network efficiency1 for I/O messages has dropped from 59% for the full 8 data byte PDU to 38%. Since the Message Body o f Explicit Message has been reduced by a byte, the best network efficiency achievable is 44%, i.e. after a reduction of 7% efficiency.
(Note : The network efficiency is calculated without taking into account the CAN protocol’s stuff bits.)
In theory, there is no limit for the number of data bytes to be transmitted via the fragmentation protocol. By analysing the network efficiency, it is obvious that transferring data longer than 8 bytes is not efficient in DeviceNet. Most o f the fragmentation data consist of the non time critical information such as the transmissions of Serial Number and Product type during initialisation phase of the network. The use o f fragmentation messages is best avoided during run-time. If circumstances allow, it is preferable to keep the fragmented I/O messages to a minimum for hard real-time systems.