Transcription
Systemhaus f r AutomatisierungCANopen Slave Protocol StackVersion 5.00
Document conventionsFor better handling of this manual the following icons and headlinesare used:This symbol marks a paragraph containing useful information aboutthe protocol stack operation or giving hints on configuration.UserThis symbol marks a paragraph which describes actions to be executedby the user of the source code package.This symbol marks a paragraph which explains possible danger. Thisdanger might cause a damage to the system or damage to personnel.Read these sections carefully!KeywordsImportant keywords appear in the border column to help the readerwhen browsing through this document.Syntax, ExamplesFor function syntax and code examples the font faceSource Code Pro is used.MicroControl GmbH & Co. KGJunkersring 23D-53844 TroisdorfFon: 49 / 2241 / 25 65 9 - 0Fax: 49 / 2241 / 25 65 9 - 11http://www.microcontrol.net
Contents1.2.3.4.5.6.7.8.Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51.1References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61.2Abbreviations . . . . . . . . . . . . . . . . . . . . . . . . . . . 61.3Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71.4Introduction to CAN . . . . . . . . . . . . . . . . . . . . . . 71.5Introduction to CANopen . . . . . . . . . . . . . . . . . . 8CANopen Slave Overview . . . . . . . . . . . . . . . . . . . . . . . . 92.1Naming Conventions . . . . . . . . . . . . . . . . . . . . . 92.2Message Router . . . . . . . . . . . . . . . . . . . . . . . . . 102.3File Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . 112.4Initialisation Process . . . . . . . . . . . . . . . . . . . . . . 12CANopen Slave Manager . . . . . . . . . . . . . . . . . . . . . . . 133.1Initialisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133.2Manager Configuration Options . . . . . . . . . . . . 153.3Manager Functions . . . . . . . . . . . . . . . . . . . . . . 16Service Data Objects - SDO . . . . . . . . . . . . . . . . . . . . . . 214.1SDO Server Configuration Options . . . . . . . . . . 214.2Object Dictionary . . . . . . . . . . . . . . . . . . . . . . . 224.3SDO Client Functions . . . . . . . . . . . . . . . . . . . . 24Process Data Objects - PDO. . . . . . . . . . . . . . . . . . . . . . 295.1PDO Configuration Options . . . . . . . . . . . . . . . 295.2PDO Functions . . . . . . . . . . . . . . . . . . . . . . . . . 30Network Management - NMT . . . . . . . . . . . . . . . . . . . . 336.1NMT Configuration Options . . . . . . . . . . . . . . . 336.2NMT Functions . . . . . . . . . . . . . . . . . . . . . . . . . 33Emergency Service - EMCY . . . . . . . . . . . . . . . . . . . . . . 377.1EMCY Producer Configuration Options . . . . . . . 377.2EMCY Producer Functions . . . . . . . . . . . . . . . . . 38Synchronisation Service - SYNC . . . . . . . . . . . . . . . . . . 398.1SYNC Configuration Options . . . . . . . . . . . . . . . 398.2SYNC Functions . . . . . . . . . . . . . . . . . . . . . . . . . 40CANopen Slave Protocol Stack Manual3
Contents9.Time Service - TIME . . . . . . . . . . . . . . . . . . . . . . . . . . . 419.1TIME Configuration Options . . . . . . . . . . . . . . . 419.2Timing Functions . . . . . . . . . . . . . . . . . . . . . . . 4210. Layer Setting Services - LSS . . . . . . . . . . . . . . . . . . . . . 4510.1LSS Configuration Options . . . . . . . . . . . . . . . . 4510.2LSS Functions . . . . . . . . . . . . . . . . . . . . . . . . . . 4511. Parameter Storage . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47A11.1Parameter Storage Configuration Options . . . . 4711.2Parameter Storage Functions . . . . . . . . . . . . . . 48Source Code Agreement . . . . . . . . . . . . . . . . . . . . . . . 51B. Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 554CANopen Slave Protocol Stack Manual
Scope1. ScopeThe CANopen Slave Protocol Stack manual describes the ApplicationProgramming Interface (API) for access to the CANopen services. TheAPI provides functionality for the CANopen standards CiA 301, CiA 302and CiA 305.The CANopen Slave Protocol Stack is independent from the used CANhardware and operating system. Access to the CAN hardware is donevia the CANpie API, which is available for a wide range of CAN controllers. The CANpie API is not subject of this manual.CANopen Slave Protocol Stack Manual51
ScopeReferences1.1 References1/1/CiA 301, CANopen Application Layer and Communication Profile, Version 4.2, CAN in Automation (CiA) e.V.http://www.can-cia.org/2/CiA 302, Additional application layer functions, Part 1 - 7, Version4.0.2, CAN in Automation (CiA) e.V.http://www.can-cia.org/3/CiA 305, CANopen Layer setting services and protocols, Version2.2, CAN in Automation (CiA) e.V.http://www.can-cia.org/4/CANpie users guide, Version 2.0, MicroControl GmbH & Co. e.html1.2 Abbreviations6APIApplication Programming InterfaceCANController area networkCAN-IDCAN identifierCOBCommunication objectCOB-IDCommunication object identifierCRCCyclic redundancy checkLSBLeast significant bit/byteMSBMost significant bit/byteOSIOpen systems interconnectionRTRRemote transmission requestCANopen Slave Protocol Stack Manual
DefinitionsScope1.3 Definitions1CAN base framemessage that contains up to 8 byte and is identified by 11 bits asdefined in ISO 11898-1CAN extended framemessage that contains up to 8 byte and is identified by 29 bits asdefined in ISO 11898-1CAN-IDidentifier for CAN data and remote frames as defined in ISO11898-11.4 Introduction to CANCAN (Controller Area Network) is an international standard defined inthe ISO 11898 for high speed and ISO 11519-2 for low speed.CAN is based on a broadcast communication mechanism. This broadcast communication is achieved by using a message oriented transmission protocol. These messages are identified by using a messageidentifier. Such a message identifier has to be unique within the wholenetwork and it defines not only the content but also the priority of themessage.The priority at which a message is transmitted compared to anotherless urgent message is specified by the identifier of each message. Thepriorities are laid down during system design in the form of corresponding binary values and cannot be changed dynamically. The identifier with the lowest binary number has the highest priority. Bus accessconflicts are resolved by bit-wise arbitration on the identifiers involvedby each node observing the bus level bit for bit. This happens in accordance with the "wired and" mechanism, by which the dominantstate overwrites the recessive state. The competition for bus allocationis lost by all nodes with recessive transmission and dominant observation. All the "losers" automatically become receivers of the messagewith the highest priority and do not re-attempt transmission until thebus is available again.The CAN protocol supports two message frame formats, the only essential difference being in the length of the identifier. The CAN standard frame, also known as CAN 2.0 A, supports a length of 11 bits forthe identifier, and the CAN extended frame, also known as CAN 2.0 B,supports a length of 29 bits for the identifier.CANopen Slave Protocol Stack Manual7
ScopeIntroduction to CANopen1.5 Introduction to CANopen1CANopen is a communication protocol and device profile specificationfor embedded systems used in automation. In terms of the OSI model,CANopen implements the layers above and including the network layer. The CANopen standard consists of an addressing scheme, severalsmall communication protocols and an application layer defined by adevice profile. The communication protocols have support for networkmanagement, device monitoring and communication between nodes,including a simple transport layer for message segmentation/desegmentation. The lower level protocol implementing the data link andphysical layers is usually Controller Area Network (CAN), although devices using some other means of communication (such as EthernetPowerlink, EtherCAT) can also implement the CANopen device profile.The basic CANopen device and communication profiles are given inthe CiA 301 specification released by CAN in Automation /1/. Profilesfor more specialized devices are built on top of this basic profile, andare specified in numerous other standards released by CAN in Automation, such as CiA 401 for I/O-modules and CiA 402 for motion control.8CANopen Slave Protocol Stack Manual
Naming ConventionsCANopen Slave Overview2. CANopen Slave OverviewThe following figure shows an overview of the CANopen Slave functionality. Each CANopen service is described in a separate chapter. ParameterStorageLSSServiceObjectDictionary EMCYServiceSYNCService SDO Server2 TIMEService PDO ServiceNMTService COSManagerCANpie–CAN DriverFig. 1: CANopen Slave overviewThe CANopen Slave Protocol Stack uses a well-defined CAN API (CANpie) to the CAN interface and thus can be adopted to any kind of CANcontroller. The CANpie API is not described in this manual, for moreinformation refer to /4/.2.1 Naming ConventionsAll functions, structures, defines and constant value of the CANopenBootloader stack have the prefix "Cos". The following table shows theused nomenclature:CANopen Slave stackPrefixFunctionsCos service name EnumerationeCOS name StructuresCos name sDefinesCOS service name Error CodeseCOS ERR name Table 1: Naming conventionsCANopen Slave Protocol Stack Manual9
CANopen Slave OverviewMessage Router2.2 Message RouterThe message router is responsible for reading and writing CAN messages between the CANopen Slave Protocol Stack and the CAN bus. TheCANpie API /4/ and its buffer concept is used to access the CAN interface on the different target platforms.2CAN messages are transmitted and received by different CAN messagebuffers. Depending on the CANopen service, a specific CAN messagebuffer will be selected.Application CANopenSlaveeCosBufNMTeCosBufNMT ERReCosBufNMT HBCeCosBufSDO RCVeCosBufSDO TRMeCosBufSYNCeCosBufLSS RCVeCosBufLSS TRMeCosBufEMCYeCosBufPDO1 RCVeCosBufPDO1 TRMeCosBufTIMECANpiebufferCAN busFig. 2: Detail view of CANpie buffers and associated CANopen services10CANopen Slave Protocol Stack Manual
File StructureCANopen Slave Overview2.3 File StructureAll header files and implementation files of the CANopen Slave ProtocolStack package are located in the source directory.FileFunctioncos conf.hCANopen Slave configuration filecos dict.c / hObject dictionary accesscos emcy.c / hEmergency servicecos led.c / hLED supportcos lss.c / hLayer Settings Service (LSS)cos mgr.c / hCANopen Slave managercos mobj.c / hManufacturer objectscos nmt.c / hNetwork management (NMT)cos pdo.c / hProcess data objects (PDO)cos sdo.c / hService data objects (SDO) servercos sync.c / hSynchronisation Service (SYNC)cos time.c / hTimer servicescos user.cApplication functions / event handlercos301.c / hObjects of CiA 3012Table 2: CANopen Slave Protocol Stack filesThe file cos user.c contains all variables and functions that requirean adoption to the target system.CANopen Slave Protocol Stack Manual11
CANopen Slave OverviewInitialisation Process2.4 Initialisation ProcessThe CANopen Slave is initialised with CosMgrInit(). This routine willsetup the CAN controller and initialise all necessary services. Afterwardsthe stack can be started by calling the CosMgrStart() function.In summary three steps are necessary to run the CANopen Slave: Initialise CANopen Slave Protocol Stack Start CANopen Slave Protocol Stack Start the timer event function2void ---------------------// Initialize the CANopen Slave stack//CosMgrInit(eCP CHANNEL 1, --------// Start the CANopen Slave,// bitrate 500 kBit/s, node-ID 1,//CosMgrStart(eCP BITRATE 500K, --------// now the CANopen Slave stack is initialized and// has to be triggered by calling CosMgrTimerEvent() with// a cycle time of COS TIMER PERIOD}Example 1:Initialization processThe initialisation functions of the CANopen Slave Protocol Stack haveto be executed prior to any other API functions.12CANopen Slave Protocol Stack Manual
InitialisationCANopen Slave Manager3. CANopen Slave ManagerThe CANopen Slave Manager covers the initialization and control ofthe protocol stack. It also manages the initialization of the CAN interface via the CANpie driver.3.1 InitialisationThe CANopen Slave stack is initialized by calling the two functionsCosMgrInit() and -------------------// Initialize the CANopen Bootloader stack//CosMgrInit(eCP CHANNEL 1, COS CONF ------------// initialization for timer and other peripheral// can be done ---------// Start the CANopen Slave Protocol Stack,// bit-rate 500 kBit/s, node-ID 1,//CosMgrStart(eCP BITRATE 500K, 1);Example 2:Initialization of CANopen Bootloader protocol stackAfter calling the CosMgrStart() CANopen Slave stack is running anda CANopen Boot-up message is send on the CAN bus (i.e. the identifier700h node-ID).The next example shows a complete generic initialisation of the protocol inside the main function. Additional functions for the microcontroller and timer are provided by the MicroControl Library (MCL), they areshown for a better understanding of the example code.CANopen Slave Protocol Stack Manual133
CANopen Slave --------------------------// Initialize the target CPU//McCpuInit();//--------------
The CANopen Slave Protocol Stack manual describes the Application Programming Interface (API) for access to the CANopen services. The API provides functionality for th e CANopen standards CiA 301, CiA 302 and CiA 305. The CANopen Slave Protocol Stack is independent from the used CAN hardware and operating system. Access to the CAN hardware is done via the CANpie API, which is available for
