How it Works
Schneider Electric
Loading...
DS301
User Manual
102 pgs807.99 Kb0
Table of contents
Loading...

Schneider Electric DS301 User Manual

IL•1F CANopen DS301
Fieldbus interface Fieldbus manual
V2.01, 11.2008
0198441113586, V2.01, 11.2008
www.schneider-electric.com
Important information IL•1F CANopen DS301

Important information

This manual is part of the product.
Carefully read this manual and observe all instructions.
Keep this manual for future reference.
Hand this manual and all other pertinent product documentation over to all users of the product.
Carefully read and observe all safety instructions and the chapter "Be­fore you begin - safety information".
Some products are not available in all countries. For information on the availability of products, please consult the cata­log.
Subject to technical modifications without notice.
All details provided are technical data which do not constitute warranted qualities.
Most of the product designations are registered trademarks of their re­spective owners, even if this is not explicitly indicated.
2 Fieldbus interface
IL•1F CANopen DS301 Table of Contents

Table of Contents

Important information. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
Table of Contents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
Writing conventions and symbols. . . . . . . . . . . . . . . . . . . . . . . 7
1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
1.1 About this manual . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
1.2 CAN-Bus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
1.3 Fieldbus devices networked via CAN bus . . . . . . . . . . . 10
1.4 Operating modes and functions in fieldbus mode . . . . . 10
1.5 Documentation and literature references . . . . . . . . . . . 11
2 Before you begin - safety information. . . . . . . . . . . . . . . . . . . 13
3 Basics. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
3.1 CANopen technology . . . . . . . . . . . . . . . . . . . . . . . . . . 15
3.1.1 CANopen description language . . . . . . . . . . . . . . . . 15
3.1.2 Communication layers . . . . . . . . . . . . . . . . . . . . . . . 15
3.1.3 Objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
3.1.4 CANopen profiles . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
3.2 Communication profile. . . . . . . . . . . . . . . . . . . . . . . . . . 19
3.2.1 Object dictionary. . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
3.2.2 Communication objects . . . . . . . . . . . . . . . . . . . . . . 21
3.2.3 Communication relationships . . . . . . . . . . . . . . . . . . 24
3.3 Service data communication . . . . . . . . . . . . . . . . . . . . . 26
3.3.1 Overview. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
3.3.2 SDO data exchange . . . . . . . . . . . . . . . . . . . . . . . . . 26
3.3.3 SDO message . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
3.3.4 Reading and writing data . . . . . . . . . . . . . . . . . . . . . 28
3.4 Process data communication . . . . . . . . . . . . . . . . . . . . 31
3.4.1 Overview. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
3.4.2 PDO data exchange . . . . . . . . . . . . . . . . . . . . . . . . . 32
3.5 Synchronization. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
3.6 Network management services . . . . . . . . . . . . . . . . . . . 46
3.6.1 NMT services for device control . . . . . . . . . . . . . . . . 46
3.6.2 NMT services for connection monitoring . . . . . . . . . 48
4 Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
Fieldbus interface 3
Table of Contents IL•1F CANopen DS301
5 Commissioning. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
5.1 Commissioning the device . . . . . . . . . . . . . . . . . . . . . . 53
5.2 Address and baud rate . . . . . . . . . . . . . . . . . . . . . . . . . 54
5.3 Commissioning the fieldbus network . . . . . . . . . . . . . . 54
5.3.1 Starting fieldbus mode . . . . . . . . . . . . . . . . . . . . . . . 54
5.3.2 Troubleshooting . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
5.4 SyCon CANopen configuration software . . . . . . . . . . . 56
5.4.1 Creating a new network . . . . . . . . . . . . . . . . . . . . . . 56
5.4.2 Selecting the CANopen master . . . . . . . . . . . . . . . . 56
5.4.3 Setting the bus parameters . . . . . . . . . . . . . . . . . . . 57
5.4.4 Selecting and inserting nodes . . . . . . . . . . . . . . . . . 58
6 Operation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
6.1 Overview. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
6.2 Using SDO commands . . . . . . . . . . . . . . . . . . . . . . . . . 61
6.2.1 Writing parameters. . . . . . . . . . . . . . . . . . . . . . . . . . 61
6.2.2 Reading a parameter . . . . . . . . . . . . . . . . . . . . . . . . 62
6.2.3 Synchronous errors . . . . . . . . . . . . . . . . . . . . . . . . . 62
6.3 Changing operating states with PDO4 . . . . . . . . . . . . . 63
6.3.1 Switching the power stage on and off . . . . . . . . . . . 64
6.3.2 Triggering a "Quick Stop" . . . . . . . . . . . . . . . . . . . . . 64
6.3.3 Resetting faults . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
6.4 Examples for the operating modes with PDO4. . . . . . . 67
6.4.1 Operating mode Profile Position:
absolute positioning . . . . . . . . . . . . . . . . . . . . . . . . . 68
6.4.2 Operating mode Profile Position:
relative positioning . . . . . . . . . . . . . . . . . . . . . . . . . . 69
6.4.3 Operating mode Profile Velocity. . . . . . . . . . . . . . . . 69
6.4.4 Position setting. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
6.4.5 Operating mode Homing . . . . . . . . . . . . . . . . . . . . . 71
6.5 Error signaling via PDO4 . . . . . . . . . . . . . . . . . . . . . . . 72
6.5.1 Synchronous errors . . . . . . . . . . . . . . . . . . . . . . . . . 72
6.5.2 Asynchronous errors . . . . . . . . . . . . . . . . . . . . . . . . 72
7 Diagnostics and troubleshooting . . . . . . . . . . . . . . . . . . . . . . . 75
7.1 Fieldbus communication error diagnostics . . . . . . . . . . 75
7.2 Error diagnostics via fieldbus . . . . . . . . . . . . . . . . . . . . 76
7.2.1 Message objects . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
7.2.2 Messages on the device status . . . . . . . . . . . . . . . . 76
7.3 CANopen error messages . . . . . . . . . . . . . . . . . . . . . . 77
7.3.1 Error register . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
7.3.2 Error code table . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
7.3.3 SDO error message ABORT . . . . . . . . . . . . . . . . . . 78
4 Fieldbus interface
IL•1F CANopen DS301 Table of Contents
8 Object directory. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
8.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
8.1.1 Specifications for the objects . . . . . . . . . . . . . . . . . . 79
8.1.2 Objects, overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
8.2 Objects of the product . . . . . . . . . . . . . . . . . . . . . . . . . . 81
9 Glossary. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
9.1 Units and conversion tables . . . . . . . . . . . . . . . . . . . . . 93
9.1.1 Length. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
9.1.2 Mass . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
9.1.3 Force. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
9.1.4 Power . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
9.1.5 Rotation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
9.1.6 Torque. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
9.1.7 Moment of inertia . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
9.1.8 Temperature . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
9.1.9 Conductor cross section . . . . . . . . . . . . . . . . . . . . . . 94
9.2 Terms and Abbreviations. . . . . . . . . . . . . . . . . . . . . . . . 95
10 Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
Fieldbus interface 5
Table of Contents IL•1F CANopen DS301
6 Fieldbus interface
IL•1F CANopen DS301 Writing conventions and symbols

Writing conventions and symbols

Work steps If work steps must be performed consecutively, this sequence of steps
is represented as follows:
쮿 Special prerequisites for the following work steps
왘 Step 1
컅 Specific response to this work step
왘 Step 2
If a response to a work step is indicated, this allows you to verify that the work step has been performed correctly.
Unless otherwise stated, the individual steps must be performed in the specified sequence.
Bulleted lists The items in bulleted lists are sorted alphanumerically or by priority. Bul-
leted lists are structured as follows:
• Item 1 of bulleted list
• Item 2 of bulleted list
–Subitem for 2
–Subitem for 2
• Item 3 of bulleted list
Making work easier Information on making work easier is highlighted by this symbol:
Sections highlighted this way provide supplementary information on making work easier.
SI units SI units are the original values. Converted units are shown in brackets
behind the original value; they may be rounded.
Example: Minimum conductor cross section: 1.5 mm
2
(AWG 14)
Fieldbus interface 7
Writing conventions and symbols IL•1F CANopen DS301
8 Fieldbus interface

IL•1F CANopen DS301 1 Introduction

1 Introduction

1.1 About this manual

This manual describes the fieldbus specifics for products in a fieldbus network addressed via CANopen DS301.

1.2 CAN-Bus

The CAN bus (Controller Area Network) was originally developed for fast, economical data transmission in the automotive industry. Today, the CAN bus is also used in industrial automation technology and has been further developed for communication at fieldbus level.
Features of the CAN bus The CAN bus is a standardized, open bus enabling communication be-
tween devices, sensors and actuators from different manufacturers. The features of the CAN bus comprise
• Multimaster capability
Each device in the fieldbus can transmit and receive data independ­ently without depending on an "ordering" master functionality.
• Message-oriented communication
Devices can be integrated into a running network without reconfigu­ration of the entire system. The address of a new device does not need to be specified on the network.
• Prioritization of messages
Messages with higher priority are sent first for time-critical applica­tions.
• Residual error probability
Various security features in the network reduce the probability of undetected incorrect data transmission to less than 10
Transmission technology In the CAN bus, multiple devices are connected via a bus cable. Each
network device can transmit and receive messages. Data between net­work devices are transmitted serially.
Network devices Examples of CAN bus devices are
• Automation devices, e.g. PLCs
•PCs
-11
.
• Input/output modules
•Drives
• Analysis devices
• Sensors and actuators
Fieldbus interface 9
1 Introduction IL•1F CANopen DS301
L
N

1.3 Fieldbus devices networked via CAN bus

Different fieldbus devices can be operated in the same fieldbus seg­ment. The CANopen bus provides a common basis for interchanging commands and data between the product described and other network devices.
Figure 1.1 Fieldbus devices in the network

1.4 Operating modes and functions in fieldbus mode

This manual only describes the protocol for the slave. See the chapters "Operation" and "Parameters" for descriptions of the operating modes, functions and all parameters of the slave:
Operating modes • Profile Velocity
• Profile position
•Homing
•Jog
Functions • Definition of direction of rotation
• Motion profile generation
•Quick Stop
• Fast position capture
Settings The following settings can be made via the fieldbus:
• Reading and writing parameters
• Monitoring the inputs and outputs of the 24 V signal interface
• Activating diagnostics and fault monitoring functions
Fieldbus mode
10 Fieldbus interface
IL•1F CANopen DS301 1 Introduction

1.5 Documentation and literature references

Manuals In addition to this fieldbus manual, the following manuals also belongs to
the product:
• Product manual, describes the technical data, installation, com­missioning and all operating modes and functions.
CAN users and manufacturers
organization
CANopen standards • CiA Standard 301 (DS301)
Literature Controller Area Network
CiA - CAN in Automation Am Weichselgarten 26 D-91058 Erlangen
http://www.can-cia.org/
CANopen application layer and communication profile V4.02, February 2002
• CiA Standard 402 (DSP402) Device profile for drives and motion control V2.0, July 2002
• ISO/DIS 11898: Controller Area Network (CAN) for high speed communication;1993
• EN 50325-4: Industrial communications subsystem based on ISO 11898 for controller device interfaces (CANopen); 2002
Konrad Etschberger, Carl Hanser Verlag ISBN 3-446-19431-2
Fieldbus interface 11
1 Introduction IL•1F CANopen DS301
12 Fieldbus interface

IL•1F CANopen DS301 2 Before you begin - safety information

2 Before you begin - safety information
The information provided in this manual supplements the product man­ual. Carefully read the product manual before you begin.
Fieldbus interface 13
2 Before you begin - safety information IL•1F CANopen DS301
14 Fieldbus interface

IL•1F CANopen DS301 3 Basics

3Basics

3.1 CANopen technology

3.1.1 CANopen description language

CANopen is a device- and manufacturer-independent description lan­guage for communication via the CAN bus. CANopen provides a com­mon basis for interchanging commands and data between CAN bus devices.

3.1.2 Communication layers

CANopen uses the CAN bus technology for data communication.
CANopen is based on the basic network services for data communica­tion as per the ISO-OSI model model. 3 layers enable data communica­tion via the CAN bus.
• Physical Layer
• Data Link Layer
• Application Layer
device communication
application Layer
data Link Layer
physical Layer
fielb bus communication
CAN-Bus
Figure 3.1 CANopen layer model
Physical Layer The physical layer defines the electrical properties of the CAN bus such
as connectors, cable length and cable properties such as bit-coding and bit-timing.
Data Link Layer The data link layer connects the network devices. It assigns priorities to
individual data packets and monitors and corrects errors.
Application Layer The application layer uses communication objects (COB) to exchange
data between the various devices. Communication objects are elemen­tary components for creating a CANopen application.
Fieldbus interface 15
3 Basics IL•1F CANopen DS301

3.1.3 Objects

All processes under CANopen are executed via objects. Objects carry out different tasks; they act as communication objects for data transport to the fieldbus, control the process of establishing a connection or mon­itor the network devices. If objects are directly linked to the device (de­vice-specific objects), the device functions can be used and changed via these objects.
Object dictionary The object dictionary of each network device allows for communication
between the devices. Other devices find all objects with which they can communicate in this dictionary.
CANopen
Communication
Process data
objects (PDO)
Service data
objects (SDO)
SYNC, EMCY
Network
management NMT
CAN-Bus
Object
directory
1000
h
3000
h
6000
h
FFFF
h
Device
functions
Application
Device profile
Specific functions
Powe r amplifier
Motor
Figure 3.2 Device model with object dictionary
Objects for describing the data types and executing the communication tasks and device functions under CANopen are included in the object dictionary.
Object index Every object is addressed by means of a 16 bit index, which is repre-
sented as a four-digit hexadecimal number. The objects are arranged in groups in the object dictionary.
Index (hex) Object groups Supported
by the drive
0000
h
0001
-009FhStatic and complex data types No
h
Reserved No
00A0h-0FFFhReserved No
1000h-1FFFhCommunication profile, standardized in DS 301 Yes
2000
-5FFFhManufacturer-specific device profiles Yes
h
6000h-9FFFhStandardized device profiles, e.g. in DSP 402 No
-FFFFhReserved No
A000
h
Table 3.1 Object index
See page 79, 8.2 "Objects of the product" for a list of the CANopen ob­jects.
Object group data types Data types are used so that the messages that are transmitted via the
network as bit streams have the same meaning for the transmitting and
16 Fieldbus interface
IL•1F CANopen DS301 3 Basics
receiving devices. Data types are declared by means of the objects of the data types.
Object groups of the profiles CANopen objects carry out various tasks in fieldbus mode. Profiles
group the objects by tasks.
Fieldbus interface 17
3 Basics IL•1F CANopen DS301

3.1.4 CANopen profiles

Standardized profiles Standardized profiles describe objects that are used with different de-
vices without additional configuration. The users and manufacturers or­ganization CAN in Automation has standardized various profiles. These include:
• DS301 communication profile
• DSP402 device profile
Application Layer
Application
Device Profile for Drives and Motion Control (CiA DSP 402)
CANopen Communication Profile (CiA DS 301)
Data Link Layer
Physical Layer
CAN-Bus
Figure 3.3 CANopen reference model
DS301 communication profile The DS301 communication profile is the interface between device pro-
files and CAN bus. It was specified in 1995 under the name DS301 and defines uniform standards for common data exchange between different device types under CANopen.
The objects of the communication profile in the device carry out the tasks of data exchange and parameter exchange with other network de­vices and initialize, control and monitor the device in the network.
Objects of the communication profile are:
• Process Data Objects = PDO
• Service Data Objects = SDO
• Objects with special functions for synchronization SYNC and for error messages and error response EMCY
• Network management NMT objects for initialization, error monitor­ing and device status monitoring.
DSP402 device profile The DSP402 device profile describes standardized objects for position-
ing, monitoring and settings of drives. The tasks of the objects include:
• Device monitoring and status monitoring (Device Control)
• Standardized parameterization
• Changing, monitoring and execution of operating modes
IMPORTANT: The product does not support the CiA 402 device profile.
Vendor-specific profiles The basic functions of a device can be used with objects of standardized
device profiles standardized. Only vendor-specific device profiles offer the complete range of functions. The objects with which the special func­tions of a device can be used under CANopen are defined in these ven­dor-specific device profiles.
18 Fieldbus interface
IL•1F CANopen DS301 3 Basics

3.2 Communication profile

CANopen manages communication between the network devices with object dictionaries and objects. A network device can use process data objects (PDO) and service data objects (SDO) to request the object data from the object dictionary of another device and, if permissible, write back modified values.
The following can be done by accessing the objects of the network de­vices
• Exchange parameter values
• Start motion functions of individual CAN bus devices
• Request status information

3.2.1 Object dictionary

Each CANopen device manages an object dictionary which contains all objects for communication.
Index, subindex The objects are addressed in the object dictionary via a 16 bit index.
One or more 8 bit subindex entries for each object specify individual data fields in the object. Index and subindex are shown in hexadecimal nota­tion with a subscript "
".
h
The following example shows the index entries and subindex entries for the object receive PDO4 mapping, 1603
Index Subindex Object Meaning
1603
1603
1603
1603
Table 3.2 Examples of index and subindex entries
00
h
h
01
h
h
02
h
h
03
h
h
Number of elements Number of subindexes 1st mapped object
R_PDO4 2nd mapped object
R_PDO4 3rd mapped object
R_PDO4
for mapping in R_PDO4.
h
First object for mapping in R_PDO4
Second object for mapping in R_PDO4
Third object for mapping in R_PDO4
Fieldbus interface 19
3 Basics IL•1F CANopen DS301
Structure of object dictionary The objects in the object dictionary are sorted by index values. Table 3.3
shows the index ranges of the object dictionary according to the CAN­open specifications.
Index range (hex)
0000
h
0001h-001FhStatic data types No
0020h-003FhComplex data types No
0040
-005FhManufacturer-specific data types No
h
0060h-007FhStatic data types for the device profiles No
0080h-009FhComplex data types for the device profiles No
00A0
-0FFFhReserved No
h
1000h-1FFFhCommunication profile Yes
2000h-5FFFhManufacturer-specific profiles Yes
6000
-9FFFhStandardized device profiles No
h
A000h-FFFFhReserved No
Table 3.3 Index ranges of the object dictionary
Object groups Supported
by the drive
Reserved No
Object descriptions inthe manual For CANopen programming of a product, the following object groups are
described in detail:
• 1xxx
• 3xxx
objects: Communication objects in this chapter
h
objects: Manufacturer-specific objects to the extent they are
h
required for controlling the product
All operating modes and functions of the product are controlled by means of manufacturer-specific objects. These functions and objects are described in the device documentation.
The manufacturer-specific objects are stored in the index range starting at 3000 documentation, it is sufficient to add 3000
. To derive the CAN index from the indexes given in the device
h
.
h
Example: The control word for a state transition has the index 28 and the subindex
1. In the CAN protocol, this results in the index 301C
28
]) and the subindex 1.
d
(3000h + 1Ch[=
h
20 Fieldbus interface
IL•1F CANopen DS301 3 Basics

3.2.2 Communication objects

Overview The communication objects are standardized with the DS301 CANopen
communication profile. The objects can be classified into 4 groups ac­cording to their tasks.
PDO T_PDO1 R_PDO1
T_PDO2 R_PDO2 T_PDO3 R_PDO3
T_PDO4 R_PDO4
Communication
SDO
T_SDO R_SDO
Figure 3.4 Communication objects; the following applies to the perspective
of the network device: T_..: "Transmit", R_..: "Receive"
objects
Special objects
SYNC EMCY
Network management
NMT Services NMT Node guarding
NMT Heartbeat
• PDOs (process data objects) for real-time transmission of process data
• SDOs (service data object) for read and write access to the object dictionary
• Objects for controlling CAN messages:
– SYNC object (synchronization object) for synchronization of net-
work devices
– EMCY object (emergency object), for signaling errors of a device
or its peripherals.
• Network management services:
– NMT services for initialization and network control (NMT: net-
work management)
– NMT Node Guarding for monitoring the network devices
– NMT Heartbeat for monitoring the network devices
Fieldbus interface 21
3 Basics IL•1F CANopen DS301
CAN message Data is exchanged via the CAN bus in the form of CAN messages. A
CAN message transmits the communication object and a variety of ad­ministration and control information.
CAN message
111 1 111 7
Data
Control
RTR-Bit
Identifier
Start-Bit
CRC
Acknowledge
>=36160..8 Byte
End-Bits
COB-ID
11 Bit
7 Bit4 Bit
CANopen message (simplified)
0..8 Byte
data carrier
1 2 3 4 5 6 70
Figure 3.5 CAN message and simplified representation of CANopen mes-
sage
CANopen message For work with CANopen objects and for data exchange, the CAN mes-
sage can be represented in simplified form because most of the bits are used for error correction. These bits are automatically removed from the receive message by the data link layer of the OSI model, and added to a message before it is transmitted.
The two bit fields "Identifier" and "Data" form the simplified CANopen message. The "Identifier" corresponds to the "COB ID" and the "Data" field to the data frame (maximum length 8 bytes) of a CANopen mes­sage.
COB ID The COB ID (Communication OBject Identifier) has 2 tasks as far as
controlling communication objects is concerned:
• Bus arbitration: Specification of transmission priorities
• Identification of communication objects
An 11 bit COB identifier as per the CAN 3.0A specification is defined for CAN communication; it comprises 2 parts
• Function code, 4 bits
• Node address (node ID), 7 bits.
Bit:10 0
1
COB-ID
2 3 4 1 2 3 4 5 6 7
Function code
0...15
Node-ID
0...127
Figure 3.6 COB ID with function code and node address
22 Fieldbus interface
IL•1F CANopen DS301 3 Basics
COB IDs of the communication
objects
The following table shows the COB IDs of all communication objects with the factory settings. The column "Index of object parameters" shows the index of special objects with which the settings of the com­munication objects can be read or modified via an SDO.
Communication object Function
code
NMT Start/Stop Service 0 0 0 0 0 0 0 0 0 0 0 0 (0
SYNC object 0 0 0 1 0 0 0 0 0 0 0 128 (80h) 1005h....1007
EMCY object 0 0 0 1 x x x x x x x 128 (80h) + node ID 1014h, 1015
T_PDO1
R_PDO1
T_PDO2
R_PDO2
T_PDO3
R_PDO3
1)
1)
1)
1)
1)
1)
0 0 1 1 x x x x x x x 384 (180h) + node ID 1800 0 1 0 0 x x x x x x x 512 (200h) + node ID 1400 0 1 0 1 x x x x x x x 640 (280h) + node ID 1801 0 1 1 0 x x x x x x x 768 (300h) + node ID 1401 0 1 1 1 x x x x x x x 896 (380h) + node ID 1802
1 0 0 0 x x x x x x x 1024 (400h) + node ID 1402 T_PDO4 1 0 0 1 x x x x x x x 1152 (480h) + node ID 1803 R_PDO4 1 0 1 0 x x x x x x x 1280 (500h) + node ID 1403 T_SDO 1 0 1 1 x x x x x x x 1408 (580h) + node ID ­R_SDO 1 1 0 0 x x x x x x x 1536 (600 NMT error control 1 1 1 0 x x x x x x x 1792 (700h) + node ID
LMT Services
NMT Identify Service
DBT Services
NMT Services
1) Not supported by the device
1)
1)
1)
1 1 1 1 1 1 0 0 1 0 x 2020 (7E4h), 2021 (7E5h)
1)
1 1 1 1 1 1 0 0 1 1 0 2022 (7E6h)
1 1 1 1 1 1 0 0 x x x 2023 (7E7h), 2024 (7F8h)
1 1 1 1 1 1 0 1 0 0 x 2025 (7E9h), 2026 (7EAh)
Node address, node ID [1...127]
COB ID decimal (hexadecimal) Index of object
parameters
)-
h
h
h
h
h
h
h
h
h
) + node ID -
h
h
h
Table 3.4 COB IDs of all communication objects
COB IDs of PDOs can be changed as required. The assignment pattern for COB IDs only specifies a basic setting.
Function code The function code classifies the communication objects. Since the bits
of the function code in the COB ID are more significant, the function code simultaneously controls the transmission priorities: Objects with a lower function code are transmitted with higher priority. For example, an object with function code "1" is transmitted prior to an object with func­tion code "3" in the case of simultaneous bus access.
Node address Every network device is configured before it is operated on the network.
The device is assigned a 7 bit node address (node ID) between 1 (01 and 127 (7F
). The device address "0" is reserved for "broadcast" trans-
h
missions which are used to send messages to all devices simultane­ously.
Fieldbus interface 23
)
h
3 Basics IL•1F CANopen DS301
Example Selection of a COB ID
For a device with the node address 5, the COB ID of the communication object T_PDO1 is:
384+node ID = 384 (180
Data frame The data frame of the CANopen message can hold up to 8 bytes of data.
In addition to the data frame for SDOs and PDOs, special frame types are specified in the CANopen profile:
• Error data frame
• Remote data frame for requesting a message
The data frames contain the respective communication objects.

3.2.3 Communication relationships

CANopen uses 3 relationships for communication between network de­vices:
• Master-slave relationship
• Client-server relationship
• Producer-consumer relationship
Master-slave relationship A network master controls the message traffic. A slave only responds
when it is addressed by the master.
The master-slave relationship is used with network management ob­jects for a controlled network start and to monitor the connection of de­vices.
) + 5 = 389 (185h).
h
Slave
Master
Master
Figure 3.7 Master - slave relationships
data
request
data
Slave
Slave
Slave
Messages can be interchanged with and without confirmation. If the master sends an unconfirmed CAN message, it can be received by a single or by several slaves or by no slave.
To confirm the message, the master requests a message from a specific slave, which then responds with the desired data.
24 Fieldbus interface
IL•1F CANopen DS301 3 Basics
Client-server relationship A client-server relationship is established between 2 devices. The
"server" is the device whose object dictionary is used during data ex­change. The "client" addresses and starts the exchange of messages and waits for a confirmation from the server.
A client-server relationship with SDOs is used to send configuration data and long messages.
Client
Figure 3.8 Client-server relationship
data
data
Server
The client addresses and sends a CAN message to a server. The server evaluates the message and sends the response data as an acknowl­edgement.
Producer-consumer relationship The producer-consumer relationship is used for exchanging messages
with process data, because this relationship enables fast data exchange without administration data.
A "Producer" sends data, a "Consumer" receives data.
Consumer
Producer
data
Consumer
Consumer
request
Producer
data
Figure 3.9 Producer-consumer relationships
Consumer
Consumer
The producer sends a message that can be received by one or more network devices. The producer does not receive an acknowledgement to the effect that the message was received. The message transmission can be triggered
• by an internal event, e.g. "target position reached"
• by the synchronization object SYNC
• a request of a consumer
For details on the function of the producer-consumer relationship and on requesting messages see chapter 3.4 "Process data communication".
Fieldbus interface 25
3 Basics IL•1F CANopen DS301

3.3 Service data communication

3.3.1 Overview

Service Data Object(SDO: Service Data Object) can be used to access the entries of an object dictionary via index and subindex. The values of the objects can be read and, if permissible, also be changed.
Every network device has at least one server SDO to be able to respond to read and write requests from a different device. A client SDO is only required to request SDO messages from the object dictionary of a dif­ferent device or to change them there.
The T_SDO of an SDO client is used to send the request for data ex­change; the R_SDO is used to receive. The data frame of an SDO con­sist of 8 bytes.
SDOs have a higher COB ID than PDOs and therefore are sent over the CAN bus at a lower priority.

3.3.2 SDO data exchange

A service data object (SDO) sends parameter data between two de­vices. The data exchange conforms to the client-server relationship. The server is the device to whose object dictionary an SDO message refers.
Client
R_SDO T_SDO
(request)
COB-ID data
CAN
Figure 3.10 SDO message exchange with request and response
COB-ID
data
(response)
T_SDO
R_SDO
Server
Message types Client-server communication is triggered by the client to send parameter
values to the server or to get them from the server. In both cases, the cli­ent starts the communication with a request and receives a response from the server.
26 Fieldbus interface
IL•1F CANopen DS301 3 Basics

3.3.3 SDO message

Put simply, an SDO message consists of the COB ID and the SDO data frame, in which up to 4 bytes of data can be sent. Longer data se­quences are distributed over multiple SDO messages with a special pro­tocol.
The device sends SDOs of up to 4 bytes data length (data). Greater amounts of data such as 8 byte values of the data type "Visible String 8" can be distributed over multiple SDOs and are transmitted successively in 7 byte blocks.
Example The following illustration shows an example of an SDO message.
SDO
581
COB-ID (581h)
1 2 3 4 5 6 7
0
00
43 10 00 01 0292 00
Data
Subindex
Index
Command Code
Figure 3.11 SDO message, example
COB ID and data frame R_SDO and T_SDO have different COB IDs.
The data frame of an SDO messages consists of:
• Command code (ccd) in which the SDO message type and the data length of the transmitted value are encrypted
• Index and subindex which point to the object whose data is trans­ported with the SDO message
• Data of up to 4 bytes
Evaluation of numeric values Index and data are transmitted left-aligned in Intel format. If the SDO
contains numerical values of more than 1 byte in length, the data must be rearranged byte-by-byte before and after a transmission.
581
Index:
1 2 3 4 5 6 7
0
00
43 10 00 01 0292 00
Data:
Hex:
10 00
h
00 02 01 92
h
Figure 3.12 Rearranging numeric values greater than 1 byte
Fieldbus interface 27
3 Basics IL•1F CANopen DS301

3.3.4 Reading and writing data

Writing data The client starts a write request by sending index, subindex, data length
and value.
The server sends a confirmation indicating whether the data was cor­rectly processed. The confirmation contains the same index and subindex, but no data.
Client
write request
COB-ID
COB-ID
ccd=
ccd
60h
ccd=
ccd=
ccd=
ccd=
Idx
1
ccd
23h
27h
2Bh
2Fh
2
Idx
2 3 4 5 6 70
1
Idx
Idx
2 3 4 5 6 70
Sidx
1
Sidx
2
1
data
data
data
data
data
data
write response
Server
Figure 3.13 Writing parameter values
Unused bytes in the data field are shown with a slash in the graphic. The content of these data fields is not defined.
ccd coding The table below shows the command code for writing parameter values.
It depends on the message type and the transmitted data length.
Message type Data length used
4 bytes 3 bytes 2 bytes 1 byte
Write request 23
Write response 60
Error response 80
27
h
60
h
80
h
2B
h
60
h
80
h
2F
h
60
h
80
h
Transmitting param-
h
eters
Confirmation
h
Error
h
Table 3.5 Command code for writing parameter values
28 Fieldbus interface
IL•1F CANopen DS301 3 Basics
Reading data The client starts a read request by sending the index and subindex that
point to the object or the object value whose value it wants to read.
The server confirms the request by sending the desired data. The SDO response contains the same index and subindex. The length of the re­sponse data is specified in the command code "ccd".
Client
read request
COB-ID
ccd=
ccd=
ccd=
ccd=
COB-ID
ccd
43h
47h
4Bh
4Fh
ccd=
Idx
2 3 4 5 6 70
1
ccd
40h
1
Idx
2
Idx
Idx
2 3 4 5 6 70
Sidx
1
Sidx
2
1
data
data
data
data
read response
data
data
Server
Figure 3.14 Reading a parameter value
Unused bytes in the data field are shown with a slash in the graphic. The content of these data fields is not defined.
ccd coding The table below shows the command code for transmitting a read value.
It depends on the message type and the transmitted data length.
Message type Data length used
4
1 byte
bytes3 bytes2 bytes
read request 40
Read response 43
Error response 80
40
h
47
h
80
h
40
h
4B
h
80
h
40
h
4F
h
80
h
Request read value
h
Return read value
h
Error
h
Table 3.6 Command code for transmitting a read value
Fieldbus interface 29
3 Basics IL•1F CANopen DS301
Error response If a message could not be evaluated without errors, the server sends an
error message. For details on the evaluation of the error message see chapter 7 "Diagnostics and troubleshooting".
Client
2 3 4 5 6 70
1
Idx
COB-ID
ccd:
ccd
80
Idx
Sidx
1
2
data
Figure 3.15 Response with error message (error response)
Server
error response
Byte 4-7 error code
30 Fieldbus interface
Loading...
+ 72 hidden pages
Buy Points How it Works FAQ Contact Us Questions and Suggestions Privacy Policy Cookie Policy Terms of Use