Fagor CANopen protocol (MCP-MCPi) User manual

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.
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. 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
5
4
3
2
1
120
Ω
CANopen
connector
DRIVE 3
4
3
2
CANopen
connector
DRIVE 2
4
3
2
CANopen
connector
DRIVE 1
7
2
5
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
5
4
3
2
1
Pin
5
4
3
2
1
Pin
5
4
3
2
1
Pin
7
25
C
A
N
o
p
e
n
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
5
4
3
2
1
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.
1
12
6
0-8 bytes 16
27
Start bit
A
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
in
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
0
ÎPDO exists
1
ÎPDO does not
exist
0
ÎRTR allowed
1
ÎRTR not allowed
0
ÎCAN ID 11 bits
1
Î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
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:
n
Î Indicator of the number of bytes that do not contain data and it is valid if e=1 and
s=1.
e
Î Indicator of a normal transfer (e=0) or expedited transfer (e=1).
s
Î 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:
n
Î Indicator of the number of bytes that do not contain data and it is zero if the size
of the segment is not indicated.
c
Î Indicator of segments to download. (c=0) if there are more segments to download
and (c=1) if it is the last segment.
t
Î 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 1 1
  • Page 2 2
  • Page 3 3
  • Page 4 4
  • Page 5 5
  • Page 6 6
  • Page 7 7
  • Page 8 8
  • Page 9 9
  • Page 10 10
  • Page 11 11
  • Page 12 12
  • Page 13 13
  • Page 14 14
  • Page 15 15
  • Page 16 16
  • Page 17 17
  • Page 18 18
  • Page 19 19
  • Page 20 20
  • Page 21 21
  • Page 22 22
  • Page 23 23
  • Page 24 24
  • Page 25 25
  • Page 26 26
  • Page 27 27
  • Page 28 28
  • Page 29 29
  • Page 30 30
  • Page 31 31
  • Page 32 32
  • Page 33 33
  • Page 34 34
  • Page 35 35
  • Page 36 36
  • Page 37 37
  • Page 38 38
  • Page 39 39
  • Page 40 40

Fagor CANopen protocol (MCP-MCPi) User manual

Type
User manual

Ask a question and I''ll find the answer in the document

Finding information in a document is now easier with AI