Fagor CANopen protocol (MCP-MCPi) User manual

Brand: Fagor

Model: CANopen protocol (MCP-MCPi)

Type: User manual

FAGOR AUTOMATION S.COOP.

MCP/MCPi

~ CANopen protocol ~

Ref. 0612

2/40 - CANopen protocol MCP/MCPi - Ref. 0612

Title MCP/MCPi. CANopen protocol.

Type of documentation Architecture, structure and communication in CANopen networks.

Name MAN_ MCP/MCPi_CANopen (in.)

Reference Ref. 0612

Software V01.05 (MCP), V01.01 (MCPi)

WinDDSSetup From version V0612 on

Electronic document MAN_MCP&MCPi_CANopen.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. 0612 CANopen protocol - 3/40

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/40 - CANopen protocol MCP/MCPi - Ref. 0612

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

INTRODUCTION

This manual offers detailed description of the CANopen protocol on the CAN board of

the MCP and MCPi drives, of the CANopen 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.0612 CANopen protocol - 5/40

GENERAL INDEX

CANopen PROTOCOL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7

Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7

Network architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7

Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7

Connection cable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8

Maximum length . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8

Network communication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9

Standard CAN frame . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9

Predetermined CANopen connection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9

NMT, Network Management. Network start-up and control process . . . . . . . . . .11

PDO, Process Data Object. Fast channel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .13

SDO, Service Data Object. Slow channel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .17

Emergency object . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .20

Description of the object dictionary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .22

Description of the PDO's. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .27

Startup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .34

CAN card description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .34

Communication speed selection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .34

Setting the node number . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .36

Status indicators . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .36

6/40 - CANopen protocol MCP/MCPi - Ref.0612

BLANK PAGE

MCP/MCPi - Ref.0612 CANopen protocol - 7/40

CANopen PROTOCOL

Introduction

CANopen is a network communication protocol based on the CAN bus system

(developed by BOSCH in the mid 80's and oriented to the automotive world).

CANopen has been defined as a uniform application layer in the DS301 standard

edited by the entity that regulates the CIA (Can In Automation) standard.

CAN is a Multi-master Bus system that differs from other Bus systems where the

modules connected to it are not addressed by the message identifiers. Thus, the

nodes can leave messages at the Bus as long as it is free of traffic. Conflicts at the

Bus are solved based on a certain priority assigned to the messages, established

at the COB ID (Communication Object Identifier) itself and clearly assigned to the

communication objects. The COB ID having the lowest value identifies the

message of highest priority. This characteristic provides an automatic regulation of

priorities at the Bus without the management of any master element.

Network architecture

 Structure

Building a simple CAN network where communication will be established with

CANopen protocol will require at least a slave element, a master element (e.g. a PC

with a CAN field bus board) and a connection cable like the one shown in

FIGURE 1.

Up to 127 independent slave elements may be used. Their node numbers may be

between 1 and 127.

All the CAN_H, CAN_L and CAN_SHLD lines and shields must be connected to

each other on the network.

Remember that node 0 does not exist as such and it is reserved for certain

generic messages used by the master element.

FIGURE 1.

Structure of a CAN network.

CANopen

MASTER

CANopen

connector

of the PC

120

CANopen

connector

DRIVE 3

CANopen

connector

DRIVE 2

CANopen

connector

DRIVE 1

120

White

Shield

Brown

CAN_H

CAN_SHLD

CAN_L

CAN_H

CAN_SHLD

CAN_L

CAN_SHLD

CAN_L

CAN_H

Note:A 120 Ω terminating resistor must be installed by the network installer at the module of

each end the CANopen bus. The network of the figure has them installed at the PC and at the

DRIVE3 modules which are the modules at the ends. If, for example, instead of PC, a DRIVE

unit were placed in that position, it will then be one end of the bus and the 120 Ω terminating

resistor would have to be installed at that DRIVE, not at the PC. 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/40 - CANopen protocol MCP/MCPi - Ref.0612

 Connection cable

Connecting the CAN card of a drive to a CANopen network requires a CAN cable

that has 2 wires and an external shield. One of the ends of the cable has a 5 prong

"Open Style" plugging connector with a 5 mm pitch. The shield must be connected

to pin 3 of this connector. For further detail, see

FIGURE 2.

All the CAN_H, CAN_L lines and the shield of each one of the module that make up

the network must be connected to each other.

The user must install an external 120 W terminating resistor at the elements of both

ends of the CAN bus (and only at them)between pins 2 and 4 of the module's Open

Style connector if the end module is a drive or pins 2 and 7 of the Sub-D M9 connector

if the end module is the PC) in order to prevent rebounds and transmission problems.



Maximum length

The following table shows the maximum length of the network depending on the

different transmission speeds:

FIGURE 2.

Connection cables for the modules connected to a CAN network.

TABLE 1. Maximum length of a CAN network depending on the transmission speed

Transmission

speed

Network length Transmission

speed

Network length

1000 kbit/s 30 meters 250 kbit/s 250 meters

800 kbit/s 50 meters 125 kbit/s 500 meters

500 kbit/s 100 meters ≤ 50 kbit/s 1000 meters

CAN H

SHIELD

CAN L

SHIELD

ISO GND

Front view of the Sub-D connector, F9 at the end of

the CAN cable

CAN cable between

PC and DRIVE1

CAN cable between

DRIVE1 and DRIVE2

CAN cable between

DRIVE2 and DRIVE3

Pin Signal Wire color

5 N.C. ----

4 CAN_H White

3 CAN_SHLD Shield

2 CAN_L Brown

1 N.C. ----

MCP/MCPi - Ref.0612 CANopen protocol - 9/40

Network communication

 Standard CAN frame

The standard CAN frames have between 44 and 108 useful bits. Also, depending

on the data sent, up to 23 filling bits may be inserted by the CAN drivers so the

maximum number of bits that may be reached when sending a frame is 131.

The identification of the bit fields in the CAN frame:

 <Start bit>: Beginning of the frame.

 <Arbitration>: Arbitration field that contains the identifier and the type of message

to be sent.

 <Control bits>: Control field that contains the number of data bytes.

 <Data field>: Data bits (from 0 to 8 bytes).

 <CRC>: Cyclic redundancy check characters according to the algorithm CRC-16.

 <Acknowledge>: Acknowledgment of the frame.

 <End>: End-of-frame bits.



Predetermined CANopen connection

With CANopen, transmitting data, triggering events, signaling error states, etc, are

done using communication objects. That's why each communication object has a

COB ID assigned to it on the network.

The most important objects in CANopen are:

 <NMT>: Network treatment objects.

 <SYNC>: Objects for synchronization.

 <EMCY>: Object for error messages.

 <PDO>: Objects for processing.

 <SDO>: Objects for service.

There is a set of pre-defined COB ID's to make it easier to set up simple CAN

networks.

FIGURE 3.

Standard CAN frame.

0-8 bytes 16

Start bit

rbitration

Control bits

Data field

CRC

Acknowledge

End

Bit Length

10/40 - CANopen protocol MCP/MCPi - Ref.0612

COB ID

Identifier of the message placed on the network implemented in the 11 bits of the

CAN frame identifier. Its structure is:

Function code 1 (emergency object) may be used to generate up to 128 different

objects depending on the node number indicated in the message. Objects whose

identifier is between 0x81 and 0xFF are emergency objects sent by the node whose

number is implicit in the identifier. The 0x80 is a different object sent by the master

element (without node number assigned to it) that has higher priority than the

emergency messages and serves to synchronize the communication bus.

The Broadcast objects (node 0) and Per-to-Per objects (node>0) are set depending

on the node number appearing or not on the message header. Broadcast objects

are interpreted by all the nodes of the bus and the Per-to-Per objects may be used

to establish conversations between to elements of the net.

- "Broadcast" objects

The COB ID of the "Broadcast" object is unique because it has no node number

assigned to it. It will be interpreted by all the nodes present on the CANopen network.

FIGURE 4.

Structure of the COB ID.

TABLE 2. "Broadcast" objects.

Object Function code

bits

COB ID Communication

parameters

NMT Module Control 0000 000h ---------

SYNC 0001 080h 1005h, 1006h, 1007h

TIME STAMP 0010 100h 1012h, 1013h

10 9 8765 4 3 2 1 0

Function Code Node number: 0 - 127

MCP/MCPi - Ref.0612 CANopen protocol - 11/40

- “Per-to-Per” objects

"Per-to-Per" objects involve establishing communication between two particular

nodes. This forces the COB ID's to include (depending on the object) the target node

number or the source node number (0-127 in both cases). Hence the range indicated

TABLE 3.

"Communications parameters" contains the communication object where the

various aspects related to that object are configured.

"PDO mapping parameters" contains the mapping object where the various

mapped objects are configured for the corresponding PDO.



NMT, Network Management. Network start-up and control process

Once voltage is applied to a CANopen node, a startup process begins initialing its

variables, doing an auto-test, etc. When done, each node sends a "Boot-up"

message through the bus to let the master element know that a new node is now

part of the CANopen network.

(Boot-Up) NMT - master

Í NMT - slaves.

When this task is successfully finished, the node automatically goes into a pre-

operational state and stays there until the master element, with network control

message (NMT), requests it to switch to an operational state:

(module control) NMT- master

Î NMT- slaves.

TABLE 3. “Per-to-Per” objects.

Object Function

code bits

COB ID PDO mapping

parameters

Communication

parameters

EMERGENCY 0001 081h-0FFh 1024h, 1015h

PDO1 tx 0011 181h-1FFh 1A00h 1800h

PDO1 rx 0100 201h-27Fh 1600h 1400h

PDO2 tx 0101 281h-2FFh 1A01h 1801h

PDO2 rx 0110 301h-37Fh 1601h 1401h

PDO3 tx 0111 381h-3FFh 1A02h 1802h

PDO3 rx 1000 401h-47Fh 1602h 1402h

PDO4 tx 1001 481h-4FFh 1A03h 1803h

PDO4 rx 1010 501h-57Fh 1603h 1403h

SDO tx 1011 581h-5FFh 1200h

SDO rx 1100 601h-67Fh 1200h

NMT Error Control 1110 701h-77Fh 1016h-1017h

Note. The concepts of the terms rx and tx must be understood from the bus' point

of view.

COB ID Byte 0

0x700 + node ID 0

COB ID Byte 0 Byte 1

0x000 CS node ID

12/40 - CANopen protocol MCP/MCPi - Ref.0612

This action may or may not be set as "Broadcast" depending on the value indicated

in byte 1 of the data field. Thus, if the value of byte 1 is zero, the action is set as

"Broadcast". If other than zero and less than 128, its value will indicate the

destination node for the command.

The value indicated in byte 0 of the data field of the CAN message sets the command

to be carried out. See the following table.

CS.

Depending on the value specified in these bytes of the data field, it is possible to

change the state of one or all the nodes of the network.

After the network has started up successfully, the master element has the option to

cyclically check that all the nodes remain active on it.

With - Node Guarding - the master element cyclically sends (under some previously

set and checked times) a broadcast message without any data; this message includes

the state of each of them and all the nodes respond to it. These messages are:

(Node Guarding) NMT- master

Î NMT- slaves.

NMT- master

Í NMT- slaves.

Status.

TABLE 4. Byte 0 of the data field of the CAN message. Command to carry out.

Command

specifier (byte 0)

NTM service

(module control)

1 Start the remote node - switch to operational state -

2 Stop the remote node - switch to stop state -

128 Enter the pre-operational state - switch to pre-operational state -

129 Initialize the node - reset the selected node or nodes -

130

Initialize the communication - reset the communication process at

the indicated node or nodes -

COB ID

0x700 + node ID

COB ID Byte 0

0x700 + node ID Bit 7 - Toggle bit - Bits 6-0 - Status

TABLE 5. Node Guarding. States.

Value Status

0 Initializing

1 Disconnecting *

2 Connecting *

3 Preparing *

4 Stopped

5 Running

127 In a stage prior to normal operation

* These states only exist if the device supports the “extended boot-up”.

MCP/MCPi - Ref.0612 CANopen protocol - 13/40

Related objects.

Alternately, a node may be configured for generating a period message called

"Heartbeat".

(Heartbeat) Producer

Î Consumer / s.

Status.

The consumer of the "Heartbeat" is usually the master element that verifies that each

node sends the "Heartbeat" message with a set period within certain margins and

will act accordingly whenever this is not true in any of the nodes.

(Sync) Producer

Î Consumer / s.

Object in charge of synchronizing the bus. It is cyclic, "Broadcast" and has maximum

priority in the bus after the NMT. It is directly related with the treatment of PDO's

Related objects.



PDO, Process Data Object. Fast channel

The process data objects (PDO's) may be used to transmit data in real time and with

high priority identifiers. The data telegrams may have a maximum of 8 Bytes. The

data may be exchanged using events or synchronously as wished. Exchanging

messages using events can drastically reduce the load in the bus in comparison with

using the synchronous mode.

Warning. The CAN board of the MCP and MCPi drives does not support this

characteristic.

100Ch Guard Time

100Dh Life Time

100Eh Node Guarding Identifier ( by default: 700 + node ID )

COB ID Byte 0

0x700 + node ID Status

TABLE 6. Heartbeat. States.

Status Meaning

0 Boot-up

4 Stopped

5 Running

127 In a stage prior to normal operation

Warning:A node cannot support "Heartbeat" and "Node Guarding" at the same

time.

COB ID

0x080

1005 h COB-ID of the synchronism message

1006 h Period of the communication cycle

1007 h Length of the synchronous window

14/40 - CANopen protocol MCP/MCPi - Ref.0612

PDO protocol

This protocol is used to transmit the data to/from the bus avoiding to overload it with

redundant information.

In PDO messages (in the data bytes), only and exclusively the values of variables

of different nodes are transmitted without sending their identifiers. In order for this

to be done without errors, the master and slave elements have previously agreed

on which variables will be sent within each PDO (mapping). This assignment is set

using “PDO Mapping Parameter” objects. The type of communication established

for each PDO (synchronized or by event) will be determined by the

“Communication Parameter” objects.

Depending on who sends the PDO message, we'll refer to transmission PDO (from

the slave element to the master) or reception PDO (from the master element to the

slave).

Mapping and type of communication

Let us suppose that the mapping object of the second transmission PDO has the

following values:.

Value Dword (32 bits)

Note. The DS301 standard sets four transmission PDO's and 4 reception PDO's

for each slave. All of them need not be implemented to meet the standard.

TABLE 7. Mapping and type of communication

Object 0x1A01

Subindex Value Meaning

0 2 Two objects are mapped in this PDO

1 0x60000208

Object: 0x6000 (*)

Subindex: 0x02

Data: 8 bits

2 0x64010110

Object: 0x6401 (*)

Subindex: 0x01

Data: 16 bits

* It is described in the following table.

TABLE 8. Description.

Bits 31-16 Bits 15-8 Bits 14-0

Index Subindex Number of data bits of the object

MCP/MCPi - Ref.0612 CANopen protocol - 15/40

Let us suppose that the communication object of the second transmission PDO has

the following values:

Value of subindex 1 (COB ID)

Value of subindex 2 ( Type of transmission )

TABLE 9. Example of object of the second PDO.

Object 0x1801

Subindex Value Meaning

0 5 The object 0x1801 has 5 subindexes

1 0x00000280 PDO exists, RTR not allowed, 11 bits id, COB ID=280h.

20xBC

The PDO transmission will be cyclic and through the bus

after receiving 188 synchronism messages.

3 0x000A

The "inhibit time" between PDO's is:

10 x 100 µs = 1 ms.

4 ---------- Reserved.

5 0x0000 Interval of the "event timer" 0.

TABLE 10. Value of subindex 1 (COB ID)

Bit 31 Bit 30 Bit 29 Bits 28-11 Bits 10-0

ÎPDO exists

ÎPDO does not

exist

ÎRTR allowed

ÎRTR not allowed

ÎCAN ID 11 bits

ÎCAN ID 29 bits

High portion

of the COB ID

(if CAN ID

has 29 bits)

Low portion

of the COB ID

(if CAN ID

has 29 bits).

COB ID

(if CAN ID has

11 bits)

TABLE 11. Value of subindex 2 (type of transmission).

Type of

transmission

Trigger condition of the PDO

( B = both required, 0 = one or both)

PDO transmission

SYNC

object

received

RTR

Received

request for

remote

transmission

Event

Value change

of the interruption

of the timer

0 B B Synchronous (SYNC), non-cyclic

1-240 O Synchronous (SYNC), cyclic

241-251 Reserved

252 B B Synchronous (SYNC) after RTR

253 O

Asynchronous (ASYNC) after

254 O O

Asynchronous (ASYNC), OEM-

specific event

255 O O

Asynchronous (ASYNC), device-

profile-specific event

16/40 - CANopen protocol MCP/MCPi - Ref.0612

where:

 <SYNC> means that the transmission of the PDO has to do with the reception

of the synchronism message.

 <ASYNC> means that the transmission of the PDO has nothing to do with the

reception of the synchronism message.

Type of transmission = 0.Synchronous and non-cyclic. The messages are only sent

when an event takes place and, in that case, the message is sent in synchronism

with the next synchronism message.

Type of transmission = 1 to 240.The PDO is transmitted after receiving the

number of synchronism messages specified in the type of transmission.

Type of transmission = 252 to 253. Values only possible in transmission PDO's.

In either case, the PDO is sent as response to an RTR frame of the master element.

The difference is that in the type of transmission = 252 it updates the variables

when receiving the synchronism and the transmission = 253 updates the variables

and sends them when receiving the RTR frame.

Type of transmission = 254.The PDO is transmitted when some OEM-specific

event occurs.

Type of transmission = 255. The PDO is transmitted when some device-profile-

specific event occurs.

Value of subindex 3 ( inhibit time or disable time)

It indicates the minimum time interval (in 100 µs increments ) elapsed between

PDO's. This time interval cannot be changed while the value of bit 31 of subindex

1 (COB ID) is 0 (the PDO exists).

Value of subindex 5 (event timer)

It indicates the value of the event timer (in 1 ms increments) when the transmission

type is 254 or 255.

Example to explain the meaning of the "time inhibit" and the "event timer".

When programming a type-254 transmission PDO that includes a position variable,

two different scenarios occur. As long as the element to send the PDO is stopped

(its position has not changed), it will not have to be sent. When programming a 10

ms event timer, even if the element does not change its position (it does not move),

it will send PDO's every 10 ms indicating its position. When starting the movement,

it will try sending PDO's constantly, thus taking up the whole bus with this information.

In order to avoid this situation, an inhibit time of 2 may be programmed so it only sends

PDO's every 2 ms while it is moving.

An event is a change of value of the variable or (if it is supported by the equipment,

communication objects with subindex 5).

MCP/MCPi - Ref.0612 CANopen protocol - 17/40

The message

According to the configuration shown in the tables mentioned earlier, the PDO

message (with the bytes that make it up) is as follows:

The PDO transmission will be cyclic and is provided to the bus after receiving 188

synchronism messages.

Related objects



SDO, Service Data Object. Slow channel

The service data objects (SDO's) may be used to read and write the entries of the

object dictionary (parameters, variables, commands, etc.). Thus, using SDO's, any

node may be configured by the master element. The SDO message, by default, has

a low priority identifier previously assigned to it. The transmitted data larger than 4

Bytes may be fragmented and that's why there are two ways to transfer an SDO:

<Expedited transfer> used to transfer of objects of less than 4 bytes

<Segmented transfer> used to transfer of objects of more than 4 bytes

Basic structures of an SDO

The basic structures of an SDO are:

Cliente Î Server / Server Î Client

or also Client

Î Server / Server Î Client

There are five request / response protocols implemented in the SDO's. They are:

 Initiate Domain Download

 Download Domain Segment

 Initiate Domain Upload

 Upload Domain Segment

TABLE 12. PDO message.

COB ID Byte 0 Byte 1 Byte 2

0x280

+ node ID

8 data bits of the

object 0x6000

Low portion of the 16 data

bits of the object 0x6000

High portion of the 16 data

bits of the object 0x6401

1004 h Number of PDO's supported

TABLE 13. SDO structure. Cliente Î Server / Server Î Client

Byte 0 Byte 1 Byte 2 Byte 3 Byte 4 Byte 5 Byte 6 Byte 7

Indicator of

command

SDO

Index

rule

objects

Subindex

rule

objects

Up to 4 data Bytes in expedited

transfer or 4 counter Bytes in

segmented transfer

TABLE 14. SDO structure. Client Î Server / Server Î Client

Byte 0 Byte 1 Byte 2 Byte 3 Byte 4 Byte 5 Byte 6 Byte 7

Indicator of SDO

command

Up to 7 data Bytes in segmented

transfer

18/40 - CANopen protocol MCP/MCPi - Ref.0612

 Abort Domain Transfer

SDO command indicators for the different protocols

where:

Î Indicator of the number of bytes that do not contain data and it is valid if e=1 and

s=1.

Î Indicator of a normal transfer (e=0) or expedited transfer (e=1).

Î Indication or not of data size. If indicated (s=0) and if not indicated (s=1).

e = 0 y s = 0

Î Data bytes reserved for the future by CiA.

e = 0 y s = 1

Î The bytes counter is in the data bytes (byte 4 LSB to byte 7 MSB).

e = 1

Î The data bytes contain the data to be downloaded.

where:

Î Indicator of the number of bytes that do not contain data and it is zero if the size

of the segment is not indicated.

Î Indicator of segments to download. (c=0) if there are more segments to download

and (c=1) if it is the last segment.

Î Toggle bit that must toggle with each consecutive segment. The first time is (t=0).

Download means writing into the object dictionary and upload reading from the

object dictionary.

TABLE 15. Initiate domain download.

Begin the domain download

bit

76543210

Client

Î 001- n es

Server

Í 011- - - - -

TABLE 16. Domain segment download.

Download the domain segment.

bit 76543210

Client

Î 000t n c

Server

Í 000t - - - -

TABLE 17. Initiate domain upload.

Begin the domain upload

bit 76543210

Client

Î 010- - - - -

Server

Í 010- n es

MCP/MCPi - Ref.0612 CANopen protocol - 19/40

A message may be aborted either by the client or by the server. It must be indicated

with the following command indicator:

When aborting the domain transfer, data bytes 0 and 1 contain the object index; byte

2, the object subindex and bytes 4-7 contain the abort code that describes the cause.

TABLE 18. Domain segment upload.

Upload the domain segment

bit 76543210

Client

Î 011t - - - -

Server

Í 000t n c

TABLE 19. Aborting the domain transfer.

Abort the domain transfer

bit 76543210

Client

Î / Í Server100- - - - -

20/40 - CANopen protocol MCP/MCPi - Ref.0612

Codes describing the possible reason to abort an SDO



Emergency object

An emergency message has 8 bytes and has the following format:

TABLE 20. Description of the possible SDO aborting codes.

Abort code Description

byte 7 byte 6 byte 5 byte 4

05 03 00 00

The toggle bit does not toggle

05 04 00 00

TimeOut for the SDO protocol

05 04 00 01 Wrong client/server command or unknown identifier

05 04 00 02

Block size unrecognized (only block mode)

05 04 00 03 Block number unrecognized (only block mode)

05 04 00 04

CRC error (only block mode)

05 04 00 05

Insufficient memory

06 01 00 00

Access to this object not supported

06 01 00 01

An attempt has been made to read a write-only object

06 01 00 02

An attempt has been made to write a read-only object

06 02 00 00

The object does not exist in the object dictionary

06 04 00 41

The object cannot be mapped to a PDO.

06 04 00 42

The size and number of mapped objects exceed the length

of the PDO

06 04 00 43

Overall parameter incompatibility

06 04 00 47

Overall device incompatibility

06 06 00 00

Access violation caused by hardware error

06 07 00 10

Incompatible data type, the length of the service parameter

is incompatible

06 07 00 12 Incompatible data type, the service parameter is too long

06 07 00 13 Incompatible data type, the service parameter is too short

06 09 00 11

The subindex does not exist

06 09 00 30 External range of values (only for writing access)

06 09 00 31

Parameter value too high

06 09 00 32

Parameter value too low

06 09 00 36 The maximum value is lower than the minimum value

08 00 00 00

Overall error / failure

08 00 00 20

The data cannot be transmitted or saved

08 00 00 21

The data cannot be transmitted or saved because the

device is under local control

08 00 00 22

The data cannot be transmitted or saved because of the

device's status

08 00 00 23 The object dictionary cannot be generated dynamically

TABLE 21. Emergency message.

COB ID Byte 0 -1 Byte 2 Byte 3 -7

0x080

+ node ID

Emergency error

code

Error register

(object 0x1001)

Error field specified by the

OEM

Page is loading ...

Fagor CANopen protocol (MCP-MCPi) User manual

Fagor CANopen protocol (MCP-MCPi) User manual

Fagor CANopen protocol (MCP-MCPi) User manual

Related papers

Other documents