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

It’s easy to create a CANopen compliant DSP-402 drive,isn’t it?Torsten Gedenkport GmbH, Germany1. IntroductionModern 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 deviceThe 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 conformitywith 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 driveThe 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 interfaceThe 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 requirementsIn 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.Further arguments against developing an individualized CANopen stack are the benefits available to the user of a ready-made stack.These include, for example, the guaranteed updating service or the special support for implementation offered by the provider of the CANopen stack.All relevant protocol stacks on the market are written in ANSI-C and therefore cover the main use case since more than 90% of the drive software is implemented in this program-ming language.This does not rule out that special parts of the drive control are written in assembler.Depending on the drive application to be realized the operation modes have to be imple-mented and their extent have to be defined. DSP-402defines operating modes with mandatory objects for each mode.Additional functionality can be implemented by optional objects and even manufacturer specific objects.The design of the CANopen interface to an existing drive application depends a lot on the requirements and on the structure of the application.The interface can contain:•the state machines defined in DS-301 and DSP-402,•the object dictionary and•a signalisation of all CANopen events.The simplest way of linking is the use of the application variables in the object dictionary. While the drive application is using the variable like before, it can be accessed via CANopen using SDOs.For further services (e.g. transmission of a PDO) the CANopen stack provides functions.pdoNr = 1;writePdoReq( pdoNr );Listing 1 - Transmission of a PDOThese functions encapsulate all related actions, like the following for the example above (listing 1):•Check of the NMT state•Check of the inhibit time, if necessary•Preparation of the PDO data by reading the corresponding values from the object dic-tionary (e.g. status word and actual position)•Transmission of the PDO, if it is asynchronous•or storage of the PDO in the SYNC buffer,if it is a synchronous PDOTo inform the application about CANopen requests, CallBack functions are used.On occurence of a CANopen event (Indication) the corresponding CallBack function is called. In this function the application can react to the event, if necessary.4. Design of the Object DictionaryThe most important part of the development of a CANopen drive is the design of the object dictionary.An object dictionary is difficult to create.In addition to the process data it contains value ranges, initialization values, access attributes and including the manufacturer’s parame-ters, which have to be set up in conformity with the standards and the application.Appli-cation data can be C variables that have to be assigned to the objects.It is sensible to maintain these data in a general data base and to use a software tool to generate the object dictionary in implementation code (mostly in C).The used database can also be used for the creation of Electronic Data Sheets (EDS).This automatically produces the advantage of an exact conformity with the implementation of the device and the EDS.If the input of the device specific interpretation of the parameters can be organized through a yet more detailed description, the developer can get a documentation of the device at the same time with little additional effort. This documentation serves not only as the basis of the user documentation, but is also helpful to maintenance and test tasks.Figure 2 - CANopen Design ToolThere are the the following advantages:•Such tools provide drive data bases, from which an object dictionary in C-code, an Electronic Data Sheet and a documentation are produced automatically.•The generated C-source code of the object dictionary is included by the application modules. This ensures the direct access to the variables (via variable names) and the access via index and sub-index.•These tools take over error-prone tasks and repetitious jobs and supports the implemen-tation part.5. Test of the CANopen driveThe next step is the integration of the drive into a network respectively the test of the drive.A CAN-analyser is indispensable for the implementation of CANopen networks and the integration of CANopen equipment.A CAN-analyser provides the online obser-vation of the bus traffic, sending unique or cyclic messages and whole message sequences as well as recording of the CAN messages and storing into logging files.It is advisable if supplementary software modules provide extended functions like a CANopen specific representation of the messages.Besides a CAN-Analyzer it is helpful to use a tool that allows the configuration of the CANopen drives in a CANopen network. Furthermore the access to the implemented CANopen services should be possible and it should be supported to write test or control applications. The test software must be able to import the EDS file or the device descrip-tion file (ISO-15745-compliant) of the device to get information about the representation of the object dictionary.For such an integration and test of CANopen devices resp. networks the CANopen Device Monitor (CDM, figure 3) can be used.Its scripting capability facilitates tests and can be used for network control.The following listing (listing 2) shows an example script for drives in the profile position mode.set targetPosition 5000go $targetPositionwaitForPDO 1 TargetReachedset actPosition [r 0x6063 0 i32]set deviation [expr $actPosition - $targetPosition]puts "Deviation: $deviation"if { $deviation > 10 } {puts "Error: Deviation too high"}Listing 2 - Position controlAt first the command to go to a defined position is sent (go).Then the script waits until the bit "TargetReached" is set in the first PDO.When the drive has reached its target position, the actual position is read and compared with the target position.If the devia-tion is too high, an error message is typed out.The above example can be extended that different control parameters can be adjusted and the respective paths can be recorded as a set of curves.Figure 3 - CDM with drive configuration componentsThe drives extension for the CDM extends it with dialogs to control the state machine and to test the profile position mode.Further the status and control words are displayed bit by bit.One tab contains the complex state machine of the DSP-402.There state changes can be triggered by mouse clicks instead of bit-wise modification in the object 0x6040.The sta-tus word can be polled cyclically with SDOs or received by PDO.The Profile Position Mode module allows the configuration of parameters like accelera-tion, velocity,deceleration and target position.The motions can be watched in a graphi-cal way and stopped by "Stop" or "Halt" to test the implementation.6. ConclusionThe development of a CANopen drive consists of the following tasks, implementation, test and integration. Besides an existing drive application or experience in drive dev e lop-ment the CANopen Source Code Stack is mandatory for the development of a CANopen drive.Normally there is nothing else what is needed.However, with the help of advanced software tools implementation, test and integration isstraightforward.Such tools provide functions like creation of object directory and EDS file, drive-specific test and configuration functions and configuration of complete CANopen networks. The last figure illustrates a complete tool-set for implementation, test and integration of a CANopen drive.Figure 4 - CANopen drives design flowReferences[1] CiA DS-301 CANopen Application Layer and Communication Profile[2] CiA DSP-402 Device Profile Drives and Motion Control[3] http://www.port.deport GmbHRegensburger Straße 7bD-06132 Halle/Saale+49 345 777 55 0service@port.de。