CANopenhigh-levelprotocolforCAN-bus资源-CSDN文库

4星 · 超过85%的资源需积分: 17 175 浏览量 2009-07-30 10:49:52 上传评论收藏 426KB PDF 举报

资源详情

资源评论

资源推荐

CANopen

20-Mar-2000

CANopen

high-level protocol for CAN-bus

H. Boterenbrood

NIKHEF, Amsterdam

March 20, 2000

Contents

1 INTRODUCTION ......................................................................................................................................... 2

2 CAL................................................................................................................................................................. 2

3 CANOPEN ..................................................................................................................................................... 3

3.1 CAN

OPEN OBJECT DICTIONARY .............................................................................................................. 3

3.2 CAN

OPEN COMMUNICATION .................................................................................................................... 5

3.3 CAN

OPEN PREDEFINED CONNECTION SET............................................................................................... 7

3.4 CANOPEN IDENTIFIER DISTRIBUTION ....................................................................................................... 8

3.5 CAN

OPEN BOOT-UP PROCESS ................................................................................................................... 9

3.6 D

ETAILS OF CANOPEN MESSAGE SYNTAX.............................................................................................. 10

3.6.1 NMT Module Control ................................................................................................................... 10

3.6.2 NMT Node Guarding.................................................................................................................... 10

3.6.3 NMT Boot-up ................................................................................................................................ 10

3.6.4 PDO............................................................................................................................................... 11

3.6.5 SDO ............................................................................................................................................... 11

3.6.6 Emergency Object ......................................................................................................................... 14

4 SUMMARY.................................................................................................................................................. 16

5 EXAMPLE OF A CANOPEN OBJECT DICTIONARY FOR DEVICES WITH CS5525 ADCS....... 17

5.1 I

NTRODUCTION....................................................................................................................................... 17

5.2 ADC READ-OUT..................................................................................................................................... 17

5.3 ADC

CONFIGURATION AND CALIBRATION............................................................................................. 18

5.4 T

HE OBJECT DICTIONARY ...................................................................................................................... 18

5.5 E

MERGENCY OBJECTS ............................................................................................................................ 22

REFERENCES .................................................................................................................................................... 23

ANopen 15-Mar-200

Version History

Version Date Comments

1.x 1998 First draft versions

2.0 1999 Change of title; change in chapter numbering; addition of CAN message syntax

details

2.0a 7 April 1999 Corrected error in table 7 and 8 captions

3.0 20 March 2000 Several additions in accordance with CiA DS301 CANopen Communication Pro-

file Version 4.0 (update from 3.0)

1 Introduction

Fieldbus networks from the OSI network model

point-of-view usually only have the layers 1 (Physi-

cal Layer), 2 (Datalink Layer) and 7 (Application

Layer) implemented. The intermediate layers are

not needed because a fieldbus network usually con-

sists of a single network segment only (no need for

Transport and Network Layer, layer 3 and 4) and

has no notion of 'sessions' (layer 5) or a need for

different internal data 'presentation' (layer 6).

The CAN (Controller Area Network) fieldbus de-

fines only the layers 1 and 2 (ISO11898); in prac-

tice these are completely handled by the CAN

hardware, significantly reducing the implementa-

tion effort for developers of the fieldbus node

firmware.

However, a high level protocol is necessary in or-

der to define how the CAN message frame's 11-bit

identifier and 8 data bytes are used. Building CAN-

based industrial automation systems guaranteeing

interoperability and interchangeability of devices of

different manufacturers requires a standardized ap-

plication layer and 'profiles', standardizing the

communication system, the device functionality and

the system administration:

♦ The application layer provides a set of services

and protocols useful to every device on the net-

work imaginable.

♦ The communication profile provides the means

to configure devices and communication data

and defines how data is communicated between

devices.

♦ Device profiles add device-specific behaviour

for (classes of) devices (e.g. digital I/O, analog

I/O, motion controllers, encoders, etc.).

The following sections describe the CAL applica-

tion layer for CAN networks on which the

CANopen standard is based and subsequently

CANopen itself and the profiles that define it.

The relation between OSI network model, CAN-

bus standards and CANopen profiles is illustrated in

Figure 1.

Figure 1. Schematic overview of CAN and

CANopen standards in the OSI net-

work model.

2 CAL

One of the existing higher layer communication

protocols for CAN-based networks –developed by

Philips Medical Systems– is CAL (CAN Applica-

tion Layer). It was adopted by the independent

CAN users and manufacturer group CAN in

Automation (CiA), developed further and pub-

lished in a series of standards [1].

CAL provides 4 application layer service elements:

1. CMS (CAN-based Message Specification):

offers objects of type Variable, Event and Do-

main to design and specify how the functional-

ity of a device (a node) can be accessed through

its CAN interface (e.g. how to up- or download

a set of data ('domain') exceeding the 8 bytes

maximum data content of a CAN-message, in-

cluding an 'abort transfer' feature).

Communication Profile CiA DS-301

Device Profile

CiA DSP-401

Device Profile

CiA DSP-404

Device Profile

CiA DSP-xxx

OSI Layer 7

Application

Layer

OSI Layer 2

Data Link

Layer

CAN Controller

Chip

CAN 2.0A

OSI Layer 1

Physical Layer

ISO 11898

+ -

Cable

CANopen

20-Mar-2000

CMS derives from MMS (Manufacturing Mes-

sage Specification), which is an OSI application

layer protocol designed for the remote control

and monitoring of industrial devices.

2. NMT (Network ManagemenT):

offers services to support network management,

e.g. to initialize, start or stop nodes, detect node

failures; this service is implemented according

to a master-slave concept (there is one NMT

master).

3. DBT (DistriBuTor):

offers a dynamic distribution of CAN identifiers

(officially called COB-ID, Communication Ob-

ject Identifier) to the nodes on the network; this

service is implemented according to a master-

slave concept (there is one DBT master).

4. LMT (Layer ManagemenT):

offers the ability to change layer parameters e.g.

change the NMT-address of a node,

or change bit-timing and baud-rate of the CAN-

interface.

CMS defines 8 priority levels in its messages,

each having 220 COB-IDs, occupying COB-IDs 1

to 1760; the remaining identifiers (0, 1761-2031)

are reserved for NMT, DBT and LMT. See Table 1.

In a CAN-network the lower the value of the

COB-ID, the higher the priority of the correspond-

ing message on the network is.

Note that this standard assumes CAN2.0A (CAN

Standard Message Frame) having an 11-bit identi-

fier, allowing a range of [0, 2047], but which -for

historical reasons- is limited to [0, 2031]. However

using CAN2.0B (CAN Extended Message Frame)

with 29-bit identifier doesn't change the picture: the

11-bits range in the table maps to the 11 most sig-

nificant bits of the 29-bits COB-ID and the COB-

ID ranges in the table will just become (much) lar-

ger.

CAN Application Layer (CAL)

COB-ID Usage

0 NMT start/stop services

1 - 220 CMS objects priority 0

221 - 440 CMS objects priority 1

441 - 660 CMS objects priority 2

661 - 880 CMS objects priority 3

881 - 1100 CMS objects priority 4

1101 - 1320 CMS objects priority 5

1321 - 1540 CMS objects priority 6

1541 - 1760 CMS objects priority 7

1761 - 2015 NMT Node Guarding

2016 - 2031 NMT, LMT, DBT services

Table 1. COB-ID (11-bit CAN-identifier) map-

ping to CAL services and objects.

3 CANopen

CAL provides all network management services

and message protocols, but it does not define the

contents of the CMS objects or the kind of objects

being communicated (it defines how, not what).

This is where CANopen enters the picture.

CANopen is built on top of CAL, using a subset of

CAL services and communication protocols; it pro-

vides an implementation of a distributed control

system using the services and protocols of CAL.

It does this in such a way that nodes can range

from simple to complex in their functionality with-

out compromising the interoperability between the

nodes in the network.

Central concept in CANopen is the Device Object

Dictionary (OD), a concept used in other fieldbus

systems as well (Profibus, Interbus-S).

Note that the Object Dictionary concept is not

part of CAL, it is an implementation aspect of

CANopen.

In the following sections we will first present the

Object Dictionary, and only then the CANopen

communication mechanisms.

3.1 CANopen Object Dictionary

The CANopen Object Dictionary (OD) is an or-

dered grouping of objects; each object is addressed

using a 16-bit index. To allow individual elements

of structures of data to be accessed an 8-bit sub-

index has been defined as well. The general layout

of the CANopen OD is shown in Table 2.

Don't be confused by all the 'data types' located in

the OD at indices below 0FFF; they're there mainly

CANopen

20-Mar-2000

for definition purposes only. The relevant range of a

node's OD lies between 1000 and 9FFF.

For every node in the network there exists an OD.

The OD contains all parameters describing the de-

vice and its network behaviour.

The OD of a node mainly exists in the form of a

database described in the EDS (see below) or on

paper. It is not necesssarily possible to 'interrogate'

a node via the CAN-bus about all its parameters in

its OD. It is sufficient if the node behaves exactly

according to its OD description on paper. The node

itself only needs to be able to present at least all

mandatory OD entries (as dictated by CANopen;

these are actually very few), and optionally any

other entries that form part of the configurable

functionality of the node.

CANopen is defined in the form of documents de-

scribing profiles.

There is the communication profile [2] describ-

ing the general form of the OD and the objects in

the OD's Communication Profile Area, the commu-

nication parameters; it also describes the CANopen

communication objects (see next section); this pro-

file applies to all CANopen devices.

Then there are the various device profiles (e.g.

[3]) defining for a particular type of devices the OD

objects; there are now about 5 different device pro-

files and several more are under development.

A profile describes for each OD object its func-

tion, its name, its index and sub-index, its data type,

whether the object is mandatory or optional,

whether the object is 'read only' or 'write only' or

'read/write', etc.

The description of a device's communication

functionality and objects and its device-specific

objects and their default values is proviced in the

form of an Electronic Data Sheet (EDS), an ASCII

file with a strictly defined syntax.

A description of the object configuration of an

individual device is called a Device Configuration

File (DCF) and has the same structure as an EDS.

Both file types are defined in the CANopen specifi-

cation.

The profiles define which OD objects are manda-

tory and which are optional; the number of manda-

tory objects is kept to a minimum allowing lean

implementations.

Optional features –in the communication part as

well as the device-specific part– can be added as

required to extend a CANopen device's functional-

ity.

If more features are required than are present in

the profile, there is plenty of space in the profile

available for the addition of manufacturer-specific

functionality.

So the part of the OD describing the communica-

tion parameters is the same for all CANopen de-

vices (i.e. object placing in the OD is the same, not

necessarily the value of the object…), the device-

specific part of the OD is different for different

(classes of) devices.

CANopen Object Dictionary

Index Object

0000 not used

0001 - 001F Static Data Types (standard data types, e.g. Boolean, Integer16)

0020 - 003F Complex Data Types (predefined structures composed of standard

data types, e.g. PDOCommPar, SDOParameter)

0040 - 005F Manufacturer Specific Complex Data Types

0060 - 007F Device Profile Specific Static Data Types

0080 - 009F Device Profile Specific Complex Data Types

00A0 - 0FFF reserved

1000 - 1FFF Communication Profile Area

(e.g. Device Type, Error Register, Number of PDOs supported)

2000 - 5FFF Manufacturer Specific Profile Area

6000 - 9FFF Standardised Device Profile Area (e.g. "DSP-401 Device Profile for

I/0 Modules" [3]: Read State 8 Input Lines, etc.)

A000 - FFFF reserved

Table 2. General CANopen Object Dictionary structure ('Index' in hexadecimal notation).

The terms 'PDO' and 'SDO' denote CANopen communication

objects, described in the next section.

CANopen

20-Mar-2000

Condition to trigger PDO

(B=both needed, O=one or both)

Trans-

Mission

Type

SYNC

RTR

Event

PDO

Transmission

0 B - B Sync, acyclic

1-240 O - - Sync, cyclic

241-251 - - - reserved

252 B B - Sync, after RTR

253 - O - Async, after RTR

254 - O O Async, manufacturer specific event

255 - O O Async, device profile specific event

SYNC= SYNC-object received.

RTR = Remote Transmission Request received (= a 'Remote Frame' CAN-message).

Event = e.g. 'Change-of-Value' or timer-interrupt.

Table 3. Definition of PDO transmission types in CANopen; for types 1 to 240 the number indicates

the number of SYNC objects between two PDO transmissions.

3.2 CANopen communication

Now that we have presented the concept of the

Object Dictionary we now will look at the messages

that are communicated in CANopen networks, their

content and their function, in other words: the

CANopen communication model (see [2]).

NB: be sure to make the distinction between OD

objects (objects in the Object Dictionary) –

characterized by their OD index and sub-index, as

described in the previous section– and communica-

tion objects or messages, characterized by their

COB-ID or CAN-identifier, described in this sec-

tion.

The CANopen communication model defines four

types of messages (communication objects):

1. Administrative message:

¾ Layer management, network management

and identifier distribution services: i.e ini-

tialisation, configuration and supervision of

the network (the latter aspect includes

'node/life guarding': see below).

¾ Services and protocols are according to the

LMT, NMT and DBT service elements of

CAL. These services are all based on a Mas-

ter-Slave concept: in a CAN-network there

is only one LMT-, NMT- or DBT-master

and one or more slaves.

2. Service Data Object (SDO):

¾ An SDO provides a client access to entries

(objects) of a device OD (the device is the

server) using the object's OD index and sub-

index, contained in the first few bytes of the

CAN-message.

¾ An SDO is implemented as a CMS object of

type 'Multiplexed Domain' according to

CAL, thus permitting transfer of data of any

length (as data is split up over several CAN

messages if necessary, which is when data

occupies more than 4 bytes).

The protocol is of the 'confirmed service'

type: a reply is generated for every CAN

message (one SDO requires 2 CAN-

identifiers). The SDO request and reply mes-

sage always contain 8 bytes (the number of

non-significant bytes is shown as part of the

first byte, which carries protocol informa-

tion), thus communication via an SDO has a

considerable overhead.

3. Process Data Object (PDO):

¾ Is used to transfer real-time data; data is

transferred from one (and only one) pro-

ducer to one or more consumers. Data trans-

fer is limited to 1 to 8 bytes (for example:

one PDO can transfer at maximum 64 digital

I/O values, or 4 16-bit analogue inputs).

It has no protocol overhead. The data con-

tent of a PDO is defined through its CAN-

identifier only and this content is assumed

known to sender as well as receiver(s) of the

PDO.

¾ Each PDO is described by 2 objects in the

Object Dictionary:

♦ PDO Communication Parameter: con-

tains which COB-ID is used by the PDO,

the transmission type, inhibit time and

timer period (see below for more details).

♦ PDO Mapping Parameter: contains a list

of objects from the Object Dictionary

that are mapped into the PDO, including

their size in bits (the producer as well as

the consumers of a PDO have to know

the mapping to be able to interpret the

contents of a PDO).

剩余22页未读，继续阅读

wsj3061101121

2013-12-05

主要看了对象字典、SDO、PDO啥的，有点用

评论收藏

内容反馈

michaldl

粉丝: 2
资源: 3

CANopen high-level protocol for CAN-bus

评论4

最新资源

CANopen high-level protocol for CAN-bus

评论4

CANopen high-level protocol for CAN-bus中文版

CANopen协议介绍（中文）

ZLGCAN通讯demo

KEEY-BUS智能控制系统图17.08.18.pdf

KEEY-BUS设备使用说明.pptx

CANopen 详细介绍

CANopen PDO-SDO应用实例讲解

CANopen协议中文简介

HMS CANopen硬件支持包HSP-0079 -S71200 -Canopen 1.0-V17版本

CANopen-CAN-ID实例

CANopen 汇川-DS402 私服电机 应用.zip

CANopen协议-PDO介绍

施耐德 ATV312 CANopen manual-EN.pdf

cm-canopen-user-manual-english.pdf

CAN-bus拓扑结构

堡盟总线绝对编码器BMSV 42, BMMV 42 CANopen? - MAGRES介绍（英文）.zip

canopen协议 第二部分 304-406

HMS CANopen硬件支持包HSP-0079 -S71200 -Canopen 1.0-V18版本.zip

堡盟总线绝对编码器BMSV 42, BMMV 42 CANopen® - MAGRES样本（英文）.zip

堡盟绝对编码器BMSH 42, BMMH 42 CANopen? - MAGRES介绍（英文）.zip

堡盟绝对编码器BMSH 58, BMMH 58 CANopen? - MAGRES介绍（英文）.zip

堡盟总线绝对编码器BMSV 58, BMMV 58 CANopen® - MAGRES 样本（英文）.zip

堡盟总线绝对编码器BMSH 58, BMMH 58 CANopen? - MAGRES样本（英文）.zip

Java第十五届蓝桥杯大赛软件JavaB组真题

SwitchHosts

安卓期末大作业（AndroidStudio开发），垃圾分类助手app，分为前台后台，代码有注释，均能正常运行

Notepad++安装包

2024北森能力测评题库.7z

微信小程序源码-合集1.rar

最新资源

CANopen 汇川-DS402 私服电机应用.zip

canopen协议第二部分 304-406