Fagor DEVICENET protocol (MCP-MCPi) User manual

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.

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 ...

Fagor DEVICENET protocol (MCP-MCPi) User manual

Fagor DEVICENET protocol (MCP-MCPi) User manual

Related papers

Other documents