FAGOR AUTOMATION S.COOP.
MCP/MCPi
∼
DeviceNet Protocol ∼
Ref.0607
2/56 - DeviceNet protocol MCP/MCPi - Ref.0607
Title MCP/MCPi. DeviceNet Protocol.
Type of documentation Architecture, structure and communication in DeviceNet networks.
Name MAN_ MCP/MCPi_DeviceNet (in)
Reference Ref.0607
Software V01.05 (MCP) - V01.01 (MCPi)
WinDDSSetup From version V06.12 on
Electronic document MAN_MCP&MCPi_DeviceNet.pdf
Headquarters FAGOR AUTOMATION S. COOP.
Bº San Andrés 19, Apdo. 144
20500 ARRASATE- MONDRAGÓN
www.fagorautomation.com
info@fagorautomation.es
Telephone: 34-943-719200
Fax: 34-943-771118 (Technical Service Department)
The information described in this manual may be subject to changes due to technical
modifications. FAGOR AUTOMATION, S. Coop. reserves the right to change the
contents of this manual without prior notice.
The contents of this manual have been verified and matched with the product
described here. Even so, it may contain involuntary errors that make it impossible
to ensure an absolute match. However, the contents of this document are regularly
checked and updated implementing the pertinent corrections in a later edition.
All rights reserved. No part of this documentation may be copied, transmitted,
transcribed, stored in a backup device or translated into another language without
Fagor Automation’s permission.
MCP/MCPi - Ref.0607 DeviceNet protocol - 3/56
WARRANTY
INITIAL WARRANTY:
All products manufactured or marketed by FAGOR carry a 12-month warranty for the end
user.
In order to prevent the possibility of having the time period from the time a product leaves our
warehouse until the end user actually receives it run against this 12-month warranty, the OEM
or distributor must communicate to FAGOR the destination, identification and installation date
of the machine by filling out the Warranty Form that comes with each product.
The starting date of the warranty for the user will be the one appearing as the installation
date of the machine on the Warranty Form.
This system ensures the 12-month warranty period for the user.
FAGOR offers a 12-month period for the OEM or distributor for selling and installing the product.
This means that the warranty starting date may be up to one year after the product has left our
warehouse so long as the warranty control sheet has been sent back to us. This translates into
the extension of warranty period to two years since the product left our warehouse. If this sheet
has not been sent to us, the warranty period ends 15 months from when the product left our
warehouse.
FAGOR is committed to repairing or replacing its products from the time when the first such
product was launched up to 8 years after such product has disappeared from the product
catalog.
It is entirely up to FAGOR to determine whether a repair is to be considered under warranty.
EXCLUDING CLAUSES:
The repair will take place at our facilities. Therefore, all shipping expenses as well as travelling
expenses incurred by technical personnel are NOT under warranty even when the unit is under
warranty.
The warranty will be applied so long as the equipment has been installed according to the
instructions, it has not been mistreated or damaged by accident or negligence and has been
handled by personnel authorized by FAGOR.
If once the service call or repair has been completed, the cause of the failure is not to be blamed
on the FAGOR product, the customer must cover all generated expenses according to current
fees.
No other implicit or explicit warranty is covered and FAGOR AUTOMATION shall not be held
responsible, under any circumstances, of the damage which could be originated.
SERVICE CONTRACTS:
Service and Maintenance Contracts are available for the customer within the warranty period
as well as outside of it.
4/56 - DeviceNet protocol MCP/MCPi - Ref.0607
DECLARATION OF CONFORMITY
Manufacturer: Fagor Automation, S. Coop.
Bº San Andrés 19, C.P. 20500, Mondragón -Guipúzcoa- (SPAIN)
We hereby declare, under our responsibility that the product:
Fagor AC Brushless Servo Drive System
consisting of the following modules and motors:
Drives modules:: MCP and MCPi series
AC Motors FXM, FKM, FSA and FSP series
mentioned on this declaration,
with the basic requirements of the European Directives 73/23/CE on Low Voltage
(Basic Safety Regulation; Electrical Equipment on Machines EN60204-1:95) and
92/31/CEon Electromagnetic Compatibility (EN 61800-3:1996, Specific Regulation
on Electromagnetic Compatibility for Servo Drive systems).
In Mondragón, 15.07.06
INTRODUCTION
This manual offers detailed description of the DeviceNet protocol on the CAN board
of the MCP and MCPi drives, of the DeviceNet architecture, structure and
communication in the network and on how to start up the unit.
When installed for the first time, it is a good idea to read the whole document.
Should you have any doubts or questions, please do not hesitate to contact our
technicians at any of our subsidiaries worldwide.
Thank you for choosing Fagor.
MCP/MCPi - Ref.0607 DeviceNet protocol - 5/56
GENERAL INDEX
DEVICENET PROTOCOL ...........................................................................................7
Introduction ............................................................................................................7
Network architecture .............................................................................................7
Structure ..................................................................................................................7
Connection cable .....................................................................................................8
Maximum length.......................................................................................................8
Network communication .......................................................................................9
Objects, classes and attributes................................................................................9
Device characteristics ...........................................................................................9
Communication model .............................................................................................9
Mandatory objects..................................................................................................27
Specific objects......................................................................................................35
Assembly ...............................................................................................................45
Startup ..................................................................................................................52
Communication speed selection............................................................................52
Setting the node number........................................................................................53
Status indicator LED's............................................................................................53
6/56 - DeviceNet protocol MCP/MCPi - Ref.0607
BLANK PAGE
MCP/MCPi - Ref.0607 DeviceNet protocol - 7/56
DEVICENET PROTOCOL
Introduction
DeviceNet has a network concept at "device" level based on CAN (Controlled Area
Network) and is regulated by the ODVA (Open DeviceNet Vendor Association). It
is mainly used in industrial automation processes and in robotics; its main
characteristic is that it allows connecting and disconnecting network elements while
the system is running.
It is also possible:
To run up to 64 nodes simultaneously on the network.
To select different transmission speeds (baudrates): 125 kBd, 250 kBd or 500
kBd thus being possible to cover different network lengths.
There are high priority process messages (I/O messages) and low priority process
messages (explicit messages).
Messages with more than 8 Bytes may be fragmented.
DeviceNet communication is based on connections and they must be established
before they are used.
All the data and functions of a unit are organized according to a model of objects.
Network architecture
Structure
Constructing a simple DeviceNet network requires a scanner (a PC with a DeviceNet
field bus card), several DeviceNet cables to connect the modules and a 24 V DC
power supply.
FIGURE 1.
Simple DeviceNet network.
5
4
3
2
1
5
3
1
DEVICENET
MASTER
24 V DC
POWER SUPPLY
5
4
3
2
1
5
4
3
2
1
0 VDC
24 VDC
120 Ω
DeviceNet
connector
4
2
120
Ω
Red
White
Grey
Blue
Black
DeviceNet
connector
DeviceNet
connector
DeviceNet
connector of
the PC
DRIVE 1 DRIVE 3
DRIVE 2
Note:The 120 Ω terminating resistors must be installed by the user at both ends of the DeviceNet bus.
The network of the figure has them installed at the DRIVE1 and DRIVE3 modules which are the modules at
the ends. If for example, the master PC were at one of the ends of the bus instead of the DRIVE1, the 120
Ω terminating resistor would have to be installed at the master PC, not at the MCP1. No resistor must be
mounted at the rest of the modules that make up the bus and are not at the ends. See figure.
8/56 - DeviceNet protocol MCP/MCPi - Ref.0607
Connection cable
Connect the CAN card of a drive to a DeviceNet network requires a DeviceNet cable
that has 4 wires and an external shield. The supply and communication wires are
shielded in pairs. One of the ends of the cable has a 5 prong "Open Style" plugging
connector with a 5 mm pitch. All the screens must be joined together and connected
to pin 3 of this connector. For further detail, see
FIGURE 2.
All the CANH, CANL lines and shields must be connected to each other in the network.
The 24 V DC must be provided by an external power supply.
The user must install an external 120 Ω terminating resistor at the elements of both
ends of the bus (and only at them) between pins 2 and 4 of the module's DeviceNet
connector) in order to prevent rebounds and transmission problems.
Maximum length
The following table shows the maximum network length depending on the selected
transmission speed:
FIGURE 2.
DeviceNet cable to connect the drive having a CAN card with to a DeviceNet network.
TABLE 1. Maximum length of a DeviceNet network depending on the selected transmis-
sion speed.
Transmission speed (rate) Network length
125 kBd 500 meters
250 kBd 250 meters
500 kBd 100 meters
CANH
SHIELD
CANL
+24V
5
1
3
4
2
5
1
3
4
2
Pin Pin
D
e
v
i
c
e
N
e
t
red
black
white
blue
shield
5
4
3
2
1
0 V
2
4
3
5
1
Pin Signal Wire color
5 +24 V red
4CANH white
3SHIELD shield
2CANL blue
10 V black
MCP/MCPi - Ref.0607 DeviceNet protocol - 9/56
Network communication
Objects, classes and attributes
DeviceNet is an object oriented protocol. Each node in the network contains a number
of objects. The terms used to describe them are:
Object <object>: is an abstract representation of individual elements within
a device. These elements are defined by their data (attributes), their external
functions (services) and their behavior.
Class <class>: A class includes common objects and is organized in
instances.
Instance <instance>: It consists of several variables (attributes). Different
instances of a class have the same attributes, the same services and the
same behavior. However, they may have different values in the variables
(attributes).
Attributes <attributes>: They represent the data provided by a device in
a DeviceNet network.
Service <service>: They may be applied to classes and to attributes. They
carry out specific actions (read, writing, etc.).
Behavior <behavior>: Defines the reaction of a device to an external event,
e.g.: how the data is processed.
Device characteristics
Communication model
Message groups
CAN messages are divided into several groups to provide different priorities
within the bus.
TABLE 2. Message groups.
Groups Usage
1 Data exchange via I/O messages
2 Reserved for applications between the master and the slaves
3 Configuration data exchange via explicit messages
4 Reserved for system administration
Remember that the priority is set at the CAN identifier.
10/56 - DeviceNet protocol MCP/MCPi - Ref.0607
Pre-defined master-slave COB-ID connection
It has 11 bits to define the following COB-ID:
Type of messages
DeviceNet has two types of messages:
I/O messages: They are messages sent by a node and received by another
node (polled I/O & change of state) or other nodes (strobe I/O). Only the data
is transmitted and there is no protocol for this type of messages.
Explicit messages: They are the ones sent by one node to another. They
consist of a request message and a response message. The CAN data field
consists of the service and the id address.
Connections of the I/O messages
The I/O messages of the DeviceNet are:
Polled I/O: It sets a cyclic data exchange between a master element and
a slave element. The cadence is set by the master element.
Strobe: It sets a cyclic data exchange between a master element and all the
slave elements (broadcast) in a single message.
TABLE 3. Definition of the 11 header bits, COB-ID.
Bit Type of message Hex range
Group
ID
Message
ID
group 1
Message
ID
group 2
109 876 543 210
0 1 1 0 1 Source MAC-ID 340h ... 37Fh
0 1 1 1 0 380h ... 3BFh
0 1 1 1 1 3C0h ... 3FFh
1 0
Source MAC-ID
0 0 0 400h ... 5F8h
1 0 0 0 1 Reserved
1 0
Target MAC-ID
0 1 0 402h ... 5FAh
1 0
Source MAC-ID
0 1 1 403h ... 5FBh
1 0
Target MAC-ID
1 0 0 404h ... 5FCh
1 0 1 0 1 405h ... 5FDh
1 0 1 1 0 406h ... 5FEh
1 0 1 1 1 407h ... 5FFh
Messages belonging to GROUP 1
Messages belonging to GROUP 2
MCP/MCPi - Ref.0607 DeviceNet protocol - 11/56
Status change: It sets a cyclic message transmission between the master
element and one of the slave elements or it causes a status changing event.
Associated with this message transmission and data exchanges, it shows the
term:
Assembly: Data structure previously agreed upon by the master and slave
elements offering a quick and easy control of the latter. It usually consists in a
number of output bytes with a (Out, commands+data) data structure transmitted
by the master element and received and interpreted by the slave; the slave then
responds to the master element with a (In, status+data) data structure . Since
the CAN frame consists of 8 data Bytes, the "assemblies" usually do not exceed
the 8 Bytes, but there could be some "assemblies" of more than 8 Bytes that could
generate more CAN frames and decrease performance at the bus in terms of
time.
EDS
The devices that implement the DeviceNet protocol may be documented by the
manufacturer. This documentation comes in a text file called EDS. The master
element can interpret this file and know, for example, the whole list of parameters
and variables available in the device. Knowing this information allows the device
to properly request what it is beforehand concerned about.
This file has the extension < .eds >.
Protocol
The CAN data frame consists of an 11-bit header referred to in CAN DeviceNet
as COB-ID followed by 8 data Bytes.
This COB-ID header determines the type of connection that will remain for the
following message. See TABLE 3.
The DeviceNet protocol is transmitted by the 8 data Bytes that precede the COB-
ID header.
The CAN frame may be represented like this:
A. Request explicit message
B. Unfragmented protocol
We refer to "unfragmented" protocol when the length of the message is such that can
be transmitted in a single CAN frame; i.e. 8 data Bytes.
If the content of the message to be transmitted exceeds the 8 Bytes, it must be
transmitted fragmented in several CAN frames.
The structure of the request message is:
COB-ID Byte 0 Byte 1 Byte 2 Byte 3 Byte 4 Byte 5 Byte 6 Byte 7
11 bits 8 bits 8 bits 8 bits 8 bits 8 bits 8 bits 8 bits 8 bits
12/56 - DeviceNet protocol MCP/MCPi - Ref.0607
Request Explicit Message Without Fragmentation Protocol.
Meaning of the terms of TABLE 4.
Frag (Fragment bit). Bit that indicates whether the message is fragmented
or not.
XID (Transaction ID). Bit used to set the relationship between a response
and its corresponding request. The server will return this bit with the same
value in a response message. The value of this field is not changed when
the client sends an explicit message for which it doesn't expect an answer.
Source MAC-ID: MAC-ID of the node to which the message is addressed.
Service code: Code of the service to perform.
R/R: Bit that indicates whether the request message or the response
message is fragmented or not.
The structure of the response message of the slave element is:
TABLE 4. Structure of the request message.
Byte bit 7 bit 6 bit 5 bit 4 bit 3 bit 2 bit 1 bit 0
0 Frag = 0 XID Source MAC-ID
1 R/R = 0 Service code
2 Class ID
3 Instance ID
4 Attribute ID
5
Service data (optional)6
7
Frag = 0 Unfragmented message
Frag = 1 Fragmented message
R/R = 0 Request message
R/R = 1 Reply message
MCP/MCPi - Ref.0607 DeviceNet protocol - 13/56
Response Explicit Message Without Fragmentation Protocol.
If any error occurs, the slave element responds with the following message:
General error codes:
TABLE 5. Structure of the response message.
Byte bit 7 bit 6 bit 5 bit 4 bit 3 bit 2 bit 1 bit 0
0 Frag = 0 XID Target MAC-ID
1 R/R = 1 Service code
2
Service data (optional)
3
4
5
6
7
TABLE 6. Structure of the response message when an error occurs.
Byte bit 7 bit 6 bit 5 bit 4 bit 3 bit 2 bit 1 bit 0
0 Frag = 0 XID Source MAC-ID
1 R/R = 1 Service code = 14h
2 General error code
3
Additional code.
Note. Assign the value of 0xFF to this field if
there is no additional code
TABLE 7. General error codes.
Code
(in hex.)
Status name Status description
00 OK
The specified object has carried out the
service successfully.
01 Connection failure
A service related to the connection failed in
the connection process.
02 Resource unavailable
The necessary resources for the object to
perform the requested service were not
available.
03 Wrong parameter value
See status code 0x20 which is the preferred
value to be used for this condition.
04 Path segment error
The path segment identifier of the segment
syntax was not understood by the
processing node. Path processing shall
stop when a path segment error is
encountered.
05 Unknown destination path
The path is referencing an object class,
instance or structure element that is not
known or is not contained in the processing
node. Path processing shall stop when a
path destination unknown error is
encountered.
06 Transferred incomplete
Only part of the expected data has been
transferred.
14/56 - DeviceNet protocol MCP/MCPi - Ref.0607
TABLE 8. General error codes.
Code
(in hex.)
Status name Status description
07 Connection lost The messaging connection was lost.
08 Unsupported service
The requested service was not
implemented or was not defined for this
object class/instance.
09 Wrong attribute value Invalid attribute data detected.
0A Error on the attribute list
An attribute in the Get_Attribute_List or
Set_Attribute_List response has a non-zero
status.
0B
Already in requested mode/
state.
The object is already in the mode/state
being requested by the service.
0C Object status conflict
The object cannot perform the requested
service in its current mode/state.
0D Object already exists
The requested instance of object to be
created already exists.
0E The attribute cannot be set
A request to modify an unchangeable
attribute has been received.
0F Privilege violation Permission/privilege checking failure.
10 Device status conflict
The current mode or status of the device does
not allow the execution of the requested
service.
11 Response data too large
The data to be transmitted in the response
buffer is larger than the allocated response
buffer.
12
Fragmentation of a primitive
value
The service specified an operation that is
going to fragment a primitive data value, i.e.
half a real data type.
13 Insufficient data
The service did not supply enough data to
perform the specified operation.
14 Unsupported attribute
The attribute specified in the request is not
supported.
15 Too much data
The service has provided more data than
expected.
16 Object does not exist
The specified object does not exist in the
device.
17
The service fragmentation
sequence is not in progress
The fragmentation sequence for this service
is not currently active for this data.
18 There is no saved attribute data
The attribute data of this object was not
saved prior to the requested service.
19 The saving operation failed
The attribute data of this object was not
saved due to a failure during the attempt.
1A
Router failure, the requested
packet is too large
The service request packet was too large for
transmission on a network in the path to the
destination. The routing device was forced to
abort the service.
MCP/MCPi - Ref.0607 DeviceNet protocol - 15/56
TABLE 9. General error codes.
1B Routing failure (router), the
response packet is too large.
The service response packet was too large
for transmission on a network in the path from
the destination. The routing device was
forced to abort the service.
1C Missing attribute list entry data. The service did not supply an attribute in a
list of attributes that was needed by the
service to perform the requested behavior.
1D Invalid list of attribute values. The service is returning the list of attributes
supplied with status information for those
attributes that were invalid.
1E Embedded service error An embedded service resulted in an error.
1F Provider specific error
A vendor specific error has been
encountered. The additional Code Field of
the error response defines the particular error
encountered. This General Error Code
should only be used when none of the Error
Codes presented in this table or within an
Object Class definition accurately reflect the
error.
20 Invalid parameter
A parameter associated with the request
was invalid. This code is used when a
parameter does not meet the requirements
of this specification and/or the requirements
defined in an Application Object
Specification.
21
Write-once value or medium
already written
An attempt was made to write to a write-
once medium (e.g. WORM drive, PROM)
that has already been written, or to modify a
value that cannot be changed once
established.
22 Invalid response received.
An invalid reply is received (e.g. reply
service code does not match the request
service code, or reply message is shorter
than the minimum expected reply size). This
status code can serve for other causes of
invalid replies.
23-24 ---------------------------------------- Reserved by CIP for future extensions.
25 Key failure in path
The key segment that was included as the
first segment in the path does not match the
destination module. The object specific
status shall indicate which part of the key
check failed.
26 Wrong path size
The size of the path which was sent with the
service request is either not large enough to
allow the request to be routed to an object or
too much routing data was included.
27 Unexpected attribute on the list
An attempt was made to set an attribute that
cannot be set at this time.
28 Wrong member ID
The member ID specified in the request
does not exist in the specified Class/
Instance/Attribute.
16/56 - DeviceNet protocol MCP/MCPi - Ref.0607
C. Fragmented protocol
If the quantity of data of the message exceeds the quantity of data supported by a
CAN frame, it will then start a fragmented communications protocol.
This protocol will be different depending on whether the master element wants to
change the value of an object in the slave element (write parameter) or only to know
its value without changing it (read parameter).
If the master wants to change the value of the object (write parameter), the protocol
begins with a message like this:
Write Parameter Explicit Message With Fragmentation Protocol Client
Î Server
(first fragment).
29 The member cannot be set
A request to modify a non-modifiable
member was received.
2A
General failure of the server
exclusive of group 2.
This error code may only be reported by
DeviceNet Group 2 only servers with 4k or
less code space and only in place of Service
not supported, Attribute not supported and
Attribute not settable.
2B-CF ------------------------------------- Reserved by CIP for future extensions.
D0-FF
Reserved for object Class and
service errors
This range of error codes is to be used to
indicate object class specified errors. This
range should only be used when none of the
error codes presented in this table
accurately reflect the error that was
encountered.
TABLE 10. Structure of the fragmented message to begin the protocol when the master
element wants to change the value of the object (write parameter).
Byte bit 7 bit 6 bit 5 bit 4 bit 3 bit 2 bit 1 bit 0
0 Frag = 1 XID Target MAC-ID
1
Type of
fragment = (0x00)
Fragment count
2 R/R = 0 Service code (0x10) - Set_Attribute_Single -
3 Class ID
4 Instance ID
5 Attribute ID
6
Data
7
Remember that this type of message structure must be used when a message
requires more than 8 data Bytes to be sent.
TABLE 9. General error codes.
MCP/MCPi - Ref.0607 DeviceNet protocol - 17/56
Meaning of the terms of TABLE 10.
Fragment Type.
Note: 0h will be the first fragment as long as the fragment count value is 0h
or 3Fh. If it is 0h, it will the first one of a series of fragments and if it is 3Fh,
it will the first and only one.
Fragment Count. Every time a fragment is sent, the count increases in one
unit. When the count reaches the value of 64, it restarts counting from 0.
Once the slave element receives this message successfully, it responds with an
acknowledgment message having the following structure:
Write Parameter Explicit Message With Fragmentation Protocol and Acknowledge
Server
Î Client.
ACK Status. It indicates whether there has been an error or not in the
message fragmentation process.
0h First fragment of the message.
1h Intermediate fragment of the message.
2h Last fragment of the message.
3h
Acknowledgement fragment of the message. Value sent by the recipient
of a fragmented message to its sender to confirm (acknowledge) that his
message has been received.
TABLE 11. Structure of the receipt acknowledgment message sent by the slave.
Byte bit 7 bit 6 bit 5 bit 4 bit 3 bit 2 bit 1 bit 0
0 Frag = 1 XID Target MAC-ID
1
Fragment
type = 3
Fragment count
2 Acknowledgment status of the received message - ACK Status -
This message is sent every time a correct fragment is received.
ACK Status = 0
There are no errors. The fragmentation is still in
ACK Status = 1 Data overflow error
18/56 - DeviceNet protocol MCP/MCPi - Ref.0607
The process goes and the master element sends the next intermediate fragments
with the following message structure:
Write Parameter Explicit Message With Fragmentation Protocol Client
Î Server
(intermediate fragments).
Each intermediate fragment of the message sent by the master element is confirmed
by the slave with an acknowledgment message. Its purpose is to inform the master
that each intermediate fragment of the message is being received properly.
Write Parameter Explicit Message With Fragmentation Protocol and Acknowledge
Server
Î Client.
Finally, the master element sends the last message. Its structure is:
Explicit Message With Fragmentation Protocol Client
Î Server (Last fragment).
TABLE 12. Structure of the intermediate fragments of the message sent by the master
element.
Byte bit 7 bit 6 bit 5 bit 4 bit 3 bit 2 bit 1 bit 0
0 Frag = 1 XID Target MAC-ID
1
Type of
fragment = (0x01)
Fragment count
2
Data
3
4
5
6
7
TABLE 13. Structure of the receipt acknowledgment message sent by the slave.
Byte bit 7 bit 6 bit 5 bit 4 bit 3 bit 2 bit 1 bit 0
0 Frag = 1 XID Target MAC-ID
1
Fragment
type = 3
Fragment count
2 Acknowledgment status of the received message - ACK Status -
TABLE 14. Structure of the last message sent by the master element.
Byte bit 7 bit 6 bit 5 bit 4 bit 3 bit 2 bit 1 bit 0
0 Frag = 1 XID Target MAC-ID
1
Type of
fragment = (0x02)
Fragment count
2
Data
3
4
5
6
7
MCP/MCPi - Ref.0607 DeviceNet protocol - 19/56
and the slave element acknowledges this last message. Its structure is:
Writte Parameter Explicit Message With Fragmentation Protocol and Acknowledge
Server
Î Client.
Now, when the master wants to read the value of an object, the protocol begins with
a message like this: Observe that its structure is identical to that of a normal explicit
message request.
Read Parameter Explicit Message With Fragmentation Protocol Client
Î Server.
The slave element responds to the message with the structure indicated next,
sending to the master the first portion of the data.
Read Parameter Explicit Message With Fragmentation Protocol Server
Î Client (first
fragment).
TABLE 15. Structure of the receipt acknowledgment message sent by the slave.
Byte bit 7 bit 6 bit 5 bit 4 bit 3 bit 2 bit 1 bit 0
0 Frag = 1 XID Target MAC-ID
1
Fragment
type = 3
Fragment count
2 Acknowledgment status of the received message - ACK Status -
TABLE 16. Structure of the message to begin the protocol when the master element wants
to read the value of the object (read parameter).
Byte bit 7 bit 6 bit 5 bit 4 bit 3 bit 2 bit 1 bit 0
0 Frag = 0 XID Source MAC-ID
1
R/R = 0
Service code (0x0E)
2 Class ID
3 Instance ID
4 Attribute ID
5
Service data (optional)6
7
TABLE 17. Structure of the message to begin the protocol when the master element wants
to read the value of the object (read parameter).
Byte bit 7 bit 6 bit 5 bit 4 bit 3 bit 2 bit 1 bit 0
0 Frag = 1 XID Target MAC-ID
1
Type of
fragment = (0x00)
Fragment count
2
Data
3
4
5
6
7
20/56 - DeviceNet protocol MCP/MCPi - Ref.0607
Once the master element receives the first data, it sends an acknowledgment
message to the slave with the following structure:
Read Parameter Explicit Message With Fragmentation Protocol and Acknowledge
Client
Î Server.
The intermediate data messages are transferred as indicated next in the following
data structures:
Read Parameter Explicit Message With Fragmentation Protocol Server
Î Client
(intermediate fragments).
The structure of the acknowledgment message sent by the master to the slave is:
Read Parameter Explicit Message With Fragmentation Protocol and Acknowledge
Client
Î Server.
TABLE 18. Structure of the acknowledgment message sent by the slave.
Byte bit 7 bit 6 bit 5 bit 4 bit 3 bit 2 bit 1 bit 0
0 Frag = 1 XID Target MAC-ID
1
Fragment
type = 3
Fragment count
2 Acknowledgment status of the received message - ACK Status -
TABLE 19. Structure of the intermediate fragments of the message sent by the slave
element.
Byte bit 7 bit 6 bit 5 bit 4 bit 3 bit 2 bit 1 bit 0
0 Frag = 1 XID Target MAC-ID
1
Type of
fragment = (0x01)
Fragment count
2
Data
3
4
5
6
7
TABLE 20. Structure of the acknowledgment message sent by the slave.
Byte bit 7 bit 6 bit 5 bit 4 bit 3 bit 2 bit 1 bit 0
0 Frag = 1 XID Target MAC-ID
1
Fragment
type = 3
Fragment count
2 Acknowledgment status of the received message - ACK Status -
Page is loading ...
Page is loading ...
Page is loading ...
Page is loading ...
Page is loading ...
Page is loading ...
Page is loading ...
Page is loading ...
Page is loading ...
Page is loading ...
Page is loading ...
Page is loading ...
Page is loading ...
Page is loading ...
Page is loading ...
Page is loading ...
Page is loading ...
Page is loading ...
Page is loading ...
Page is loading ...
Page is loading ...
Page is loading ...
Page is loading ...
Page is loading ...
Page is loading ...
Page is loading ...
Page is loading ...
Page is loading ...
Page is loading ...
Page is loading ...
Page is loading ...
Page is loading ...
Page is loading ...
Page is loading ...
Page is loading ...
Page is loading ...
/