CANopen devds402_对象字典设计(德国)

It’s easy to create a CANopen compliant DSP-402 drive,

isn’t it?

Torsten Gedenk

port GmbH, Germany

1. Introduction

Modern drives systems can be adapted to the most different custom-designed require-ments and integrated into all sorts of communication networks. As a robust field bus sys-tem CANopen finds increasingly use in drive applications. Therefore many users are fac-ing the necessity to integrate the CANopen communication profile into their drives.

Figure 1 - Structure of a CANopen device

The CANopen software must provide all components necessary for a CANopen drive as represented in the figure 1.To achieve this, the following considerations play a decisive role:

1. How to achieve the fastest and most cost effective implementation in conformity

with the CANopen standard?

2. How is the implementation carried out?

3. Which software tools are available?

4. Which of these are, in addition, useful?

This article describes how a CANopen drive can be developed successfully in shortest time with the aid of software tools.

2. Components of a CANopen drive

The CiA has published different standards for the communication in a CANopen net-work. The available CANopen services are defined in the communication profile DS-301. Special drive functions with their parameters are defined in the "Device profiles Drives and Motion Control" DSP-402.The DSP-402 defines the behavior of a drive at the start, the configuration and the execution of motion sequences by a state machine.

A CANopen drive can be divided into following parts:

•drive application

•communication stack and special drive profile in conformity with the standards DS-301 and DSP-402.

•object dictionary

•CAN driver interface

The drive application is not CANopen specific and therefore shall not be examined in detail. The communication interface and protocol software provide services to transmit and to receive communication objects over the bus. The object dictionary describes these data types, communication objects and application objects used in this drive.Conse-quently the most important part of a CANopen drive is the object dictionary.All data and parameter of a drive,which should be visible from CAN, are stored in the object dictio-nary and can be reached via the object dictionary.It is the interface to the application software. The application program provides the internal control functionality as well as the interface to the process hardware interfaces. The CAN driver is the interface to send and receive CAN messages.

Possible realization variants are:

•drive application and CANopen communication on one micro controller or

•further use of the available drive controller and CANopen communication on a separate communication processor with a RS485 connection, a dual port RAM or another solu-tion for data interchange.

The advantage of the first variant are the lower manufacturing costs.In contrast to that the second variant ensures that the full power of the micro controller is available for the drive control. Additionally,the reuse of existings drive components may save dev e lop-ment time.

3. Software requirements

In order to implement the CANopen functionality an individualized CANopen stack could be developed or alternatively,an already available CANopen stack could be uti-lized.

The efforts for the development of an individually designed CANopen stack appears to be substantial when the necessary standards and possible requirements of implementing the CANopen conformance tests, together with the CANopen drive,are taken into considera-tion. This means that it would be preferable to invest in an available stack.