Home
CANopen User Manual - SYS TEC electronic GmbH
Contents
1. DfPdo Obj Lgs Store Nmtm Sync Emce Hbc Instanztabelle Instanztabelle PDO SDOS SDOC LSSS EMCC EMCP NMTS NMTM HBC HBP NMT OBD COB CDRV Applikation CCM Schicht CANopen Stack CAN Treiber Schicht Verzeichnisstruktur COPstack CDRV 0 uadoNV2O User Layer 2 1 1 CANopen Stack The CANopen stack is portable this means it is implemented independent from any hardware or application specific environment COB The COB layer provides services for transmission of communication objects and therefore serves as a base layer that is required in any of the configuration variants OBD The OBD module provides the global data structure for all CANopen instances All data structures that are configurable by the user are created in this module This includes the object dictionary as well as tables for managing PDOs and SDO Server and Clients NMT This module creates the NMT state machine and calls the Callback function for the NMT state change in the CCM module NMTS This module provides services for Node Guarding Life Guarding and Boot up as NMT slave It is not possible to use both NMTS and at the same time within one CANopen instance NMTM This module provides services for Node Guarding Life Guarding and Boot up as master It is not possible to use both and N
2. 221 94 tWindowsParam 390 SYNC Callback Function144 145 147 248 265 Synchronization Objects 30 lat EE Onet 406 DL ano 405 TARGET_HARDWARE349 402 405 Telegram 5 eee 43 TGT CANOPEN LEDS 186 TGT SWITCH ERROR LED 182 187 TGT SWITCH RUN LED 186 Time Stamp Object 30 Transmission Protocols 41 116 tVxDType eere 390 User aedis 45 Variable Callback Function54 95 250 Windows sisa Ae ne a a ea Nama a 383 SYS electronic GmbH 2006 L 1020e_12 427 CANopen Software 428 SYS TEC electronic GmbH 2006 L 1020e 12 Suggestions for Improvement Document CANopen Software Manual Document number L 1020e_12 May 2006 How would you improve this manual Did you find any mistakes in this manual page Submitted by Customer number Name Company Address Return to SYS TEC electronic GmbH August Bebel Str 29 D 07973 Greiz Germany Fax 449 0 3661 62 79 99 SYS TEC electronic GmbH 2005 L 1020e 12 Published by EL SYS TEC electronic GmbH 2005 Ordering No L 1020e_12 Printed in Germany
3. D SOME ee i CcmConvertFloat 174 COP ERBE eie 405 COP MALLOC 405 CcmDefineNmtSlaveTab 138 Se etre CcmDefinePdoTab 119 INSTANCES 348 CcmDefineStaticPdoTab 177 COP USE CDRV FUNCTION PO 93 INTER cene 349 CcmEmccDefineProducerTab 148 COP USE OPERATION SYSTEM CcmEnterCriticalSectionPdoProcess 352 622396 USE SMALL TIME 352 CcmHbcDefineProducerTab 159 COpCfg h uude itt Pte baie 403 CemlnitCANopen 86 Calculation ss 230 CemlnitEmcc 148 367 415 155 CemlnitLes ene 125 data afFdy ose ed does 178 266 CemlnitN 137 Data Structures 54 204 c nit ID WAN KG ee ites a pe ee D CcmlnitStore 2222 222 128 Development Environment 372 CemlnitSyncConsumetr 144 Directory Structure 52 DR3032 3 181 422 SYS electronic GmbH 2006 1 1020 12 CcmLeaveCriticalSectionPdoProcess HbpProcess sar ba eaaa iioa 329 397 NmtExecCommand 295 CcmLockCanopenThreads 380 NmtmAddsSlaveNode 300 CcmLockedCopyData 381 NmtmConfigLgm
4. 199 M Mae cU QM CM on CcmCbLsssEvent 104520022 a ay eS OY S 99 CemStPdo 5 ERa 175 142 CcmSync 144 CcmCbhRestore 222200 132 CDRV ia 48 ComCbStore o raso debuts 130 CDRV CAN SPEC 356 CcmCbStoreLoadObject 134 CDRV IDINFO ALGO 357 CcmCbSyncReceived 147 IDINFO ENTRIES 358 Callback Function 281 INSTANCES 354 Bit Reales susce citet 404 CDRV RX BUFF ENTRIE CAN Dryer sss coco ese 403 S HIGH etai ie us 371 Selection 402 CDRV MAX RX BUFF ENTRIE CAN ERROR LED 182 185 S sath 371 CAN RUN LED 181 184 CDRV MAX TX BUFF ENTRIE CANopen DLL 383 384 HIGE e e 371 CANopen Stack 47 CDRV MAX TX BUFF ENTRIE CANopen Stack Configuration 348 Se imas luec trn 371 CANopen Stack Functions 203 358 402 CDRV_USE_BASIC_CAN 355 SC oes ttiv RR NDS 49 CDRV USE 356 CCM CONVERT LSSCMD TO L CDRV USE IDVALID 356 SSFLA G heb Wi oes 195 CDRV USED CAN CONTROLLE CCM_DR303_USE_BICOLOR_LE 355 EX
5. 407 SYS TEC electronic GmbH 2006 L 1020e 12 CANopen Software SYS TEC electronic GmbH 2006 L 1020e 12 Fundamentals Preface This manual describes the application layer as well as the supported communication objects of the CANopen stack for programmable CANopen devices Device profiles are profile specific and described in a separate manual Section provides general information on CANopen related terms and concepts Section 2 describes the implementation of the CANopen stack protocol by SYS TEC electronic GmbH and gives detailed information about the user functions their interfaces and data structures Section3 provides specific information on how to use and implement the CANopen stack in a user application with regards to the user hardware the operating system and development environment SYS TEC electronic GmbH 2006 L 1020e 12 11 CANopen Software 12 SYS TEC electronic GmbH 2006 L 1020e 12 Fundamentals 1 CANopen Fundamentals CANopen is a profile family for industrial communication with distributed automation control devices based on the CAN bus It was developed by the manufacturer and users association CiA and has been standardized since late 2002 as CENELEC EN 50325 4 CANopen has established itself in a number of areas of industrial communication e g mechanical engineering drive systems and components medical devices building automation vehicle const
6. 83 SS 195 Expedited Download Abend A La KN 228 EMCP_EVENT_ERROR_DELETEA Expedited Upload 230 ET onsite dis a NA d 405 EMCP_EVENT_ERROR_LOG 157 2 P Ccm303lnitIndicators 182 ssmCmdInquireProductCode 195 kLssmCmdInguireRevisionN 195 Ccm303ProcessIndicators 183 ssmCmdInquireRevisionN kLssmCmdInquireSerialN 195 Ccm303SetErrorState 185 ssmCmdlInquireSerialNr kLssmCmdInguireVendorld 195 Ccm303SetRunState 183 ssmCmdlnquireVendorId kLssmEv ActivateBitTimi 200 CcmBootNetwork 173 ssmEvActivateBitTiming kLssmEvActivateBusContact 200 CcmClearPreDefinedErrorField 153 ssmEvActivateBusContact CemConfisEmc 152 kLssmEvDeactivateBusContact 200 16 kLssmEvModeSelecti 200 CemConfigHbp 162 ssmEvModeSelective kLssmEvResult 200 61 08 2222 126 ssmEvResult kLssModeConfi 190 CemConfigSyncConsumer 145 ssModeConfiguration kLssModeOperati 190 CemConigS yncProducer 146 ssModeOperation CemConnectToNet 92 kLssModesSelective
7. 290 tEmcParam 150 tHbcProdParam 159 tLinuxParam sees 378 tI SsAddress eee 190 tLssCbParam 104 tLssmBitTiming 193 Process Data Objects 17 Process Variables 202 PAROS TRO SA 212 Reset Communication 121 121 Reset Communication 36 Return 336 SAM eins aa nagan NG saa ndan nei 367 415 426 SYS electronic GmbH 2006 L 1020e 12 Index tLssmldentifyParam 198 tLssmResult eese 201 2 333 tNmtmSlavelnfo 305 tNmtmSlaveParam 303 tObdCbParam 281 tObdCbStoreParam 134 tObdVStringDomain 284 tPdoError eee 102 tPdoParam 120 tPdoStaticParam 177 tSdocCbFinishParam 242 232 108 237 tSdocTransferParam 112 240 5 216
8. Module Description Functions This module contains the global CcmInitCANopen initializing and process functions hutD AN for CANopen as well as the Se response to important events CcmDefineVarTab state change of the state ComConnectToNet machine transmission errors state CcmProcess CcmCbNmtEvent CcmCbErrorEvent CcmObj c This module contains functions CcmWriteObject for _ accessing the object CemReadObject dictionary CcmDfPdo c This module contains a function CcmDefinePdoTab for defining the PDOs via a table The way of not using software modules that are not required for a specific applications is partially supported by the linkers This means that a module can be included within an IDE project but will not be included in the linking process when no function call to this module is performed SYS TEC electronic GmbH 2006 L 1020e 12 49 CANopen Software CcmStore c This module defines functions for CcmInitStore SOLUS object Hara rori MEDU 2 CcmStoreCheckArchivState dictionary in the non volatile memory CcmCbStore CcmCbRestore CcmCbStoreLoadObject CemSync c This module defines functions for CcmInitSync the SYNC consumer It supports _ the SYNC configuration CcmCbSync This module defines functions for CcmInitEmcc the Emergency NO D CcmEmcc
9. eese 168 TegtCavCreate esee 164 TegtCavDelete 165 TgtCavGetAttrib 171 TgtCavInit tein 163 TgtCavOpen 167 TegtCavRestore sss 170 TgtCavShutDown 163 5 222 2 169 TgtFnableCanlInterrupt 407 TgtFnableGloballnterrupt 406 TegtGetCanBase ses 407 TegtGetTickCount 406 407 406 TetInitCanlsr sees 406 TetInitSerial sess 406 Petit Timer iere 406 TgtMemCpy 405 407 TgtMemsSet 405 407 TetTimerlst t 406 GLOBAL i 399 Hardware Specific Layer 48 HBC Callback Function158 161 318 324 kCobTypRmtRecv 290 kCobTypRmtSend 290 kCobTypSetd ciel 290 Kernel Dryers sostenute 383 Kernel Mode Driver 376 kLssmEvldentifyAnySlave 200 kLssmEvInquireData 200 kLsssEvActivateBitTiming 105 kLsssEvConfigureBitTiming 105 kLsssEvConfigureNodeld 105 kLsssEvDeactivateBusContact 105 kLsssEvEnterConfiguration 105 kLsssEvEnterOperation 105 kLsssEvPreResetNode 105 kLsssEvSaveConfiguration
10. 187 Inn come eter tectae 403 CCM MODULE DR303 3 182 Cisco E Led 402 CCM MODULE INTEGRATION Certification 412 182 353 1 303 3 181 CCM_USE_STORE_RESTORE 354 COB Callback Function 288 294 Cemal 181 COB 288 Cemboot enses 173 CcmbDYfPdo ues 119 SYS TEC electronic GmbH 2006 L 1020e 12 421 CANopen Software COB_MAX_RX_COB_ENTRIES Dynamic Memory Management 405 Soest facet fest ee on AI 288 371 Callback Function147 148 COB_MAX_TX_COB_ENTRIES 150 307 310 Ag eei atte alas bi 288 371 EMCC_MAX_CONSUMER 371 COB_MORE_THAN_ 128 ENTRIE USE EVENT CALLBACK Orden O D fiiv te BDO ctn t KAN 363 COB MORE THAN 256 ENTRIE EMCP USE PREDEF ERROR FI Suscipe Ie Eid 358 inne iliis 363 SEARCHALOGO 359 Eimer ee li Vases cote etu ee Rede 30 Communication Objects 288 Emergency Consumer Module 307 Communication Parameters 202 205 Emergency Error Codes 346 Communication Profile 40 Emergency Producer Module 313 Constant Error Callback Function 100 LSSFLAGS ALL 195 Error Handling 42 LSSFLAGS SLAVE ADDRE Event
11. 105 kNmtCommEnterOperational 140 296 kNmtCommEnterPreOperational 140 296 kNmtCommEnterStopped 140 296 kNmtCommilnitialize 296 kNmtCommResetCommunication ols 140 296 kNmtCommhResetNode 140 296 kNmtCommStartRemoteNode 140 296 kNmtCommStopRemoteNode 140 296 kNmtErrCtrIEvBootupReceived 143 HbpNintEvent etes 328 kNmtErrCtrlEvHbcConnected 161 He rtbeat ies 36 38 kNmtErrCtrlEvHbcConnectionLost Heartbeat Consumer 161 Heartbeat Consumer Module 318 kNmtErrCtrlEvHbcNodeStateChang Heartbeat Producer 38 cant MESE DM E 161 Heartbeat Producer Module 325 kNmtErrCtrlEvLgConnected 127 Indicator Specification 181 kNmtErrCtrlEvLgLostConnection Inhibit Time 2n endet 127 Initialization eerren 35 kNmtErrCtrlEvLgMsgLost 127 INITIALIZATION 74 92 kNmtErrCtrlEvLgNoAnswer 143 INITIALIZING ierit 76 kNmtErrCtrlEvLgNodeStateChange Instance Handle 66 MCN ONDES 143 Instance Pointers 67 kNmtErrCtrlEvLgSuspended 143 Intel ette 408 kNmtErrCtrlEvLgToggleError 143 kCobTypForceRmtRecv 29 kNodeStatelnitialisation 278 kCobTypForceSend 29 kNodeStateOperatio
12. slave DSPManf Object dictionary for a manufacturer specific object dictionary l The ODBuilder tool supports the generation of an object dictionary based on an EDS file The user can also define entries in the OD The ODBuilder creates a new EDS file as well as the C and header files necessary to create the CANopen data structures 52 SYS TEC electronic GmbH 2006 L 1020e 12 User Layer Target This folder contains hardware specific files startup files for different targets subfolders required for proper initialization DK16_543 Files for Fujitsu Devkit16 with F543 CPU PC167 Files for phyCORE 167 KC167 Files for KitCON 167 505 Files for KitCON 505 515 Files for KitCON 515 linux Files for linux PC565 Dateien fiir phyCORE 565 Motorola MPC 565 Projects This folder contains the project folders for various example applications One configuration file copcfg h is provided for each project This file defines the supported hardware the supported properties and protocols 16x 100 Example project for Infineon 16x with external 0 SJA1000 Fuj_543 Example project for Fujitsu MB90F543 with internal CAN controller Inf_505 Example project for Infineon 505 with internal CAN controller Inf_515 Example project for Infineon 515 with internal CAN controller The include files have been linked to the C files without any path ind
13. 10 9 8 7 6 3 4 3 2 1 0 Function Code Node Number The node number be assigned locally or with the help of LSS services over the CAN bus SYS TEC electronic GmbH 2006 L 1020e 12 43 CANopen Software Object COB ID Object Dictionary Index Broadcast messages NMT 0000 0 SYNC 0001 0x80 0 1005 0 1006 0 1007 0010 0 100 0 1012 0 1013 5 Point to point messages Emergency 0001 1 127 0x81 OxFF 0 1014 0 1015 TPDOI 0011 1 127 Ox181 Ox1FF 0 1800 RPDOI 0100 1 127 0x201 0x27F 0 1400 TPDO2 0101 1 127 0 281 0 2 0 1801 RPDO2 0110 1 127 0x301 0x37F 0 1401 TPDO3 0111 1 127 0 381 0 3 0 1802 RPDO3 1000 1 127 0 401 0 47 0x1402 TPDO4 1001 1 127 0 481 4 0x1803 RPDO4 1010 1 127 0 501 0 57 0x1403 Default 1011 1 127 0 581 0 5 0x1200 SDO tx Default 1100 1 127 0 601 0 67 0 1200 SDO rx NMT Error 1110 1 127 0 701 0 77 0x1016 0x1017 Control Table 13 Pre defined Master Slave Connection Set 1 44 SYS TEC electronic GmbH 2006 L 1020e 12 User Layer 2 CANopen User Layer The following section describes the data structures and API functions of the SYS TEC electronic GmbH specific implementation of the CANopen standard CiA DS 301 Support for additional CANopen standards is al
14. Note The clock speed for various CAN controllers might be different depending on the hardware that is used Thus differences in the register values for the corresponding baud rate may occur The CiA DSP 305 standard also describes further LSS services Description of these services is not provided in this manual Please refer to applicable documentation provided by the CiA User s group 34 SYS TEC electronic GmbH 2006 L 1020e 12 Fundamentals 1 3 Network Management Several other network services for supervision of networked nodes are provided in CANopen besides the services for configuration and data exchange NMT network management services require one CANopen device in the network that assumes the tasks of an NMT master Such tasks include initialization of NMT slave distribution of identifiers node supervision and network booting among others 1 3 1 1 NMT State Machine CANopen defines a state machine that controls the functionality of a device Transition between the individual states is initiated by internal events or NMT master services These device states can be connected to application processes power on Pre Operational NE wc E Figure 12 state machine for CANopen devices In Initialization state the CANopen data structures of a node are initialized by the application The CiA DS 301 standard defines various mandatory OD entries for this task as well as specific comm
15. aga aa saa 246 EmcpAddInstance 314 SdocAddlnstance 233 313 SdocDefineClient 236 2 2221 316 SdocDeleteInstance 234 EmcpSendEmergency 317 9 244 326 SOON em ettet 231 HbcAddInstance 320 SdocInitTransfer 239 HbcDeletelInstance 321 234 tete 319 245 HbcNmtEvent sss 322 SdocUndefineClient 238 HbcSetEventCallback 324 SdosAbort eese 225 HbpDeleteInstance 327 SdosAddInstance 217 Hbplnit med 325 SdosDefineServer 220 SYS TEC electronic GmbH 2006 L 1020e 12 423 CANopen Software SdosDeleteInstance 218 Sdosl nit 5 bees 215 218 SdosProcess 224 SdosUndefineServer 223 TegtCanlsrxxx 407 TgtCavCheckValid 172 TegtCavClose
16. 3 6 Typical Configuration of a CANopen Device as NMT Slave 409 3 7 Typical Configuration of a CANopen Device as NMT Master 410 4 Notes on CANopen Certification 1 412 5 Cn Di amp e M 414 6 Revision History CANopen 5 1 416 DING EN qe gah 421 SYS TEC electronic GmbH 2006 L 1020e 12 CANopen Software Index of Figures and Tables Figure 1 Figure 2 Figure 3 Figure 4 Figure 5 Figure 6 Figure 7 Figure 8 Figure 9 Figure 10 Figure 11 Figure 12 Figure 13 Figure 14 Figure 15 Figure 16 Figure 17 Figure 18 Figure 19 Figure 20 Figure 21 Figure 22 Figure 23 Figure 24 Figure 25 Figure 26 Figure 27 Overview of the CANopen 14 Communication model for eese 17 Mapping of Object Dictionary entries into a PDO 19 Data transmission of object data via 5 28 Structure of an emergency message 3l Switch Mode Global Service eden tees rai aient 32 Configure Bit Enning Service 33 Response to Configure Bit Timing service 39 Activate Bit Timing service 2 2 33 Configure Node ID service aee be rhet pee eerte ehe ares 3
17. Figure 15 Heartbeat message Meaning of the status byte corresponds to that of the Node Guarding message refer to Figure 13 In contrast to the Node and or Life Guarding bit 7 of the status byte does not change after each transmission It always contains the value 0 This is also not necessary here because a Full CAN controller cannot send this message automatically since this protocol is not based on remote frames It is the application s task to initiate the transmission of the Heartbeat message Setting the producer Heartbeat time entry 0x1017 in the object dictionary to Zero disables the Heartbeat producer 38 SYS TEC electronic GmbH 2006 L 1020e 12 Fundamentals 1 3 1 6 Heartbeat Consumer The Heartbeat consumer analyzes Heartbeat messages sent from the producer In order to monitor the producer the consumer requires every producer s node number as well as the consumer Heartbeat time The information is stored in the Object Dictionary at entry 0x1016 For every monitored producer there is a corresponding sub entry that contains the node number of the producer and the Consumer Heartbeat Time Bit 31 24 23 16 15 0 Value 0 00 Node number Consumer Heartbeat Time Table 11 Heartbeat consumer configuration The consumer is activated when a Heartbeat message has been received and a corresponding entry is configured in the OD value different from 0 If the Heartbeat time configured
18. 0401p2km SYS TEC electronic GmbH 2006 L 1020e 12 61 CANopen Software Index Sub Object Data Attribute Default index Type Type Value 0x1800 transfer PDO record parameter 0 largest sub indexsub var 8 ro 5 index supported 1 COB ID used by PDO var u32 rw store 0 8000 0000 2 transfer type var us rw store 255 3 inhibit time var ul6 rw store 0 5 event timer var ul6 rw store 0 18 0 1 00 transfer PDO mapping record 0 number of mapped var u8 rw store 0 application objects in PDO 1 8 PDO mapping for the var u32 rw store 0 n th application object to be mapped OxlAxx 0 6000 read input 8 bit array 0 number of inputs 8 bit var 18 const 16 1 16 read input var 18 mapp 0 0 6100 read input 16 bit array 0 number of inputs 16 var u8 const 8 bit 1 8 read input var 416 mapp 0 0 6200 write output 8 bit array 0 number of outputs 8 var 18 const 16 bit 1 16 write output var us rw mapp 0 26 Not present in the ODs for the CANopen Starter Kit 401 2 and o401p2km 62 SYS TEC electronic GmbH 2006 L 1020e 12 User Layer Index Sub Nane Object Data Attribute Default index T Type Value ype 0x63004 write output 16 bit array 0 number of outputs 16 var 08 const 8 bit 1 8 write output var 416 rw mapp 0
19. Application Error Application errors are errors such as short circuit under voltage exceeding temperature thresholds code or RAM errors as well as conditions not permitted such as alarms and disturbances The Application and network layer signalize such errors However it is the application s task to analyze process and signalize these errors CANopen provides the communication object Emergency to report such errors over the CAN bus Identifier Data 0 1 2 3 4 5 6 7 0 080 Emergency Error N Error Code Register ode Number Index 0x1003 0x1001 manufacturer specific information Figure 5 Structure of an emergency message The DS 301 standard as well as the applicable device profiles for CANopen define specific error codes for transmission of error states The emergency message can also contain manufacturer specific data that further describes the error The transmitted error code indicates the error that occurred The error register assigns certain categories to groups of errors and indicates if errors still exist within the corresponding category If the error disappears the CANopen device will transmit a message with the error code reset high portion equals zero At the same time the data content of the error register that is also transmitted in this message indicates if other errors still exist Each CAN controller has an internal error counter This error counter is
20. Parameter User Layer Object Dictionary Index Subindex Entry 0x2000 0 UINT8 1 UINT8 2 UINT16 3 UINT16 0 2010 0 UINT8 1 REAL32 2 DOMAIN 0 6000 0 UINT8 1 UINT8 2 UINT8 Figure 17 Data exchange between application and object dictionary Read _ 2 CAN Bus SDO Upload Parameter Index Subindex SDO Download Parameter Index Subindex Write and Read with the help of SDO Transmit with the help of PDOs SYS TEC electronic GmbH 2006 L 1020e 12 57 CANopen Software 2 4 Object Dictionary The Object Dictionary is defined in three files objdict c objdict h and obdcfg h An exact description for the Object Dictionary creation is given in manual L 1024 CANopen software comes in three standard variants These variants are listed in the following sections In the listing of objects abbreviations are used for the object type the data type and for the attributes These abbreviations have the following meanings Object Types var Object contains a value that can be accessed per SDO or from the application variable Data Types u8 Unsigned 8 bit 416 Unsigned 16 bit u32 Unsigned 32 bit 18 Integer 8 bit 116 Integer 16 bit 132 Integer 32 bit vstr Visible String Attribute ro read only object can be read per SDO and read or written from the application rw read write object can be read or written per SDO or from the applicatio
21. 188 32 LSS slave ete Rees 188 ESS Slaves hen s 32 LSS INVALID NODEID 279 55 CONFIRM TIMEOUT 370 PRE OPERATIONAL 278 STOBPBDkss 278 callback function 202 NMT Callback Function74 78 93 99 110 202 295 Command 295 Commands 300 Error 222 2 101 Master Module 300 Module 295 Slave Module 297 State Machine 35 101 295 NMTM MAX SLAVE ENTRIES MU 371 NMTS USE LIFE GUARDING 363 Node Guarding 36 Node 279 Node State 278 268 OBD CHECK FLOAT VALID 360 OBD CHECK OBJECT RANGE saang chad a 269 OBD_CHECK_OBJECT_RANGE mies 360 OBD_OBJ SIZE 260 OBD OBJ SIZE MIDDLE 260 OBD OBJ SIZE SMALL 269 OBD_SUPPORTED_OBJ_SIZE 269 OBD_SUPPORTED_OBJ_SIZE 359 OBD_USE_DYNAMIC_OD 360 OBD_USE_STRING_DOMAIN_IN RAM 360 USER OC 280 Object Callback Function122 130 132 205 214 227 2771 273 281 LSSM PROCESS DELAY TIME Object Dictionary 41 58 370 Object Dict
22. 302 CcmLssmConfigureSlave 191 NmtmDeleteSlaveNode 301 CemLssmldentifySlave 197 NmtmGetSlavelnfo 304 CcmLssmInquireldentity 194 NmtmProcess eene 306 CemLssmS witchMode 189 NmtmSendCommand 305 CcmPdoSendMPDO 334 NmtmTriggerNodeGuard 303 CemProcess ae eec 98 8 5 2422222 298 CcmProcessLsslnitState 97 NmtsSendBootup 297 124 NmtsSetLgCallback 299 CemSdocAbort eese 118 ObdAccessOdPart 274 CcmSdocDefineClientTab 107 277 5 8 115 269 CcmSdocStartTransfet 111 ObdGetNodeld 279 154 ObdGetNodeState 278 CcmSendNmtCommand 139 ObdReadEnttry 272 CcmSendThreadEvent 382 394 ObdRegisterUserOd 280 CemShutDownCANopen 91 270 CemsSignalCheckVar 144
23. E Pe itd 181 PAN AL EON E TRENT 188 2 7 20 Communication Parameters and Process Variables 202 2 8 Description of the CANopen Stack Functions 203 2 0 SDOS d rv rd bate pud ndi t dpt 203 2 8 2 SDOC Module op eit deberia 225 DB Se ELDON LOO Gy coh aen RR S En 247 2 840 PDOSTC MIOOHIE ss sasar PORE FO D Moda a Ka 265 20 9 OBD MO dU E coe 268 200 COB Module te DR 288 2R O NME DAG ete 295 2 8 8 NMT Slave Mod le ss sesanan kae emis e ee 297 2 86 9 INMT Master Module oie atero cda 300 2 8 10 Emergency Consumer Module sss 307 2 8 11 Emergency Producer Module sess 313 2 8 12 Heartbeat Consumer 318 2 8 13 Heartbeat Producer Module esses 325 2 9 Add on modules for the CANopen protocol stack 331 2 9 1 MPDO Module Multiplexed PDO 331 2 9 2 CcmMPdo Modul Multiplexed PDO 334 2 10 Meaning of Return Values and Abort Codes 336 2 10 1 CANopen Return 336 2 102 SDO Abort CodeS qub aep ek o aaa ades Re 344 2 10 3 Emergency Error Codes
24. TPDO Mapping Parameter Ox1A00 0 Number of entries XY Ox1A00 1 1 Map Object 0x1A00 2 2 Map Object 0x60000208 0x60000308 TPDO Communication Parameter 0x1800 0 Number of entries 0x1800 1 COB ID 0x1800 2 Transmission Type 2 0 01 0 259 Resulting TPDO 0 01 0 SYS electronic GmbH 2006 L 1020e 12 23 CANopen Software Device B 0 1000 Device 0 6200 1 0 6200 2 0 6200 3 Output 1 8 Bit Output 2 8 Bit Output 3 8 Bit RPDO Parameter 0 1600 0 0 1600 1 0 1600 2 Number of entries 1 Object 2 Object 0 lt 620001068 0 lt 62000308 RPDO Communication Parameter 01400 0 Number of entries 01400 1 COB ID 0x1400 2 Transmission Type 0 01 0 255 Resulting RPDO 0x01C0 Output 1 Output 3 Transmit and receive PDOs utilize the same CAN identifier 0 01 0 Thus device B automatically receives the PDO transmitted by device A The recipient device B analyzes the data in accordance to its mapping scheme it passes the first byte to output 1 and the second byte to output 3 On the other hand the transmitting device A stores its inputs 2 and 3 in exactly these bytes This proofs the correct input output assignment and PDO mapping 24 SYS TEC electronic GmbH 2006 L 1020e 12 Fundamentals 1 2 1 4 Transmission Type Sub index 2 The transmission type of a TPDO defines under
25. kNmtEvPostResetCommunication Table 20 state machine explanation List of events and commands According to the standard CiA DS 301 the following services are to be supported in the various NMT states SYS TEC electronic GmbH 2006 L 1020e 12 77 CANopen Software Communi INITIALISING OPERATIONAL STOPPED cation OPERATIONAL object PDO X SDO X X SYNC X X Time Stamp X X Emergency X X Boot Up X NMT X X X Table 21 Supported communication objects in various states 4 The function CcmConnectToNet starts the execution of the State machine with the state INITIALIZING After a state has been closed the state machine will shift to the next state on its own until reaching the state PRE OPERATIONAL The function CcmConnectToNet will then return During execution of the individual states respective events the modules of the CANopen stack will be called repeatedly over the XxxNmtEvent function Likewise a call will be performed for the applications NMT Callback function AppCbNmtEvent if a function has been parameterized entry m fpNmtEventCallback of the structure tCcmInitParam When Callback function is called the event is given as a parameter event will be handed over as parameter refer to Table 20 The function AppCbNmtEvent is called as the last function within the execution sequence of an NMT state s XxxNmtEvent functions allo
26. write 0 to erease 1 4 standard error field var u32 ro 0 0x1005 COB ID SYNC var u32 rw store 0x080 0x1006 communication cycle var u32 rw store 0 period 0x1007 synchronous window var u32 rw store 0 length 0x1008 manufacturer device var vstr const CANopen name Slave 0x1009 manufacturer hardware var vstr const V1 00 version 0 100 manufacturer software var vstr const 5 version 0 100 guard time var 416 store 0 23 23 Not present in the ODs for the Master 0401p3m 0401p7m 0401p2km SYS TEC electronic GmbH 2006 L 1020e 12 59 CANopen Software Index Sub Name Object Data Attribute Default index Type Type Value 0x100D life time factor var 18 rw store 0 1 0 1010 store parameters array 0 largest sub index var 18 const 3 supported 1 save all parameters var u32 rw 2 save communication var 132 rw parameters 3 save application var u32 rw 0 parameters 0x1011 restore default array parameters 0 largest sub index var 18 const 3 supported 1 restore all default var u32 rw 0 parameters 2 restore communication var u32 rw 0 default parameters 3 restore application var u32 rw 0 default parameters 0x1012 COB ID time stamp var u32 rw store 0x100 message 0 1014 COB ID emergency var u32 rw store 0 8000 message 0000 0 1015 inhibit time var 116 rw store 0 0 1016
27. Dictionary or the last value saved in the non volatile memory The application can change the values of process variables at a later time Example tCopKernel PUBLIC AppCbNmtEvent tNmtEvent NmtEvent p tCopKernel Ret kCopSuccessful which event is called switch NmtEvent_p case kNmtEvEnterInitialising break case kNmtEvResetNode reset process vars wDigiOut 0 break SYS TEC electronic GmbH 2006 L 1020e 12 79 CANopen Software State RESET COMMUNICATION Here all communication parameters starting at 0x1000 to Ox1 FFF are reset to their power on values Power on value refers to the default value from the Object Dictionary or the last value saved in the non volatile memory The communication objects for all modules in the CANopen stack are created The application can now redefine all PDOs With this all settings are overwritten by the default values from the OD or the values stored in the non volatile memory The state machine changes automatically to PRE OPERATIONAL state after completion CANopen slave signals this state transition by sending a BOOTUP message 29 power on values the last values stored in the object 0x1010 Save Parameters in as far as they are not reset to their default values with the object 0x1011 Restore Parameters It is up to the user to arrange the upload of Object Dictionary entries into a non volatile memo
28. considered to be complete The description of functions parameters and implementation can be found in the applicable CCM module SYS TEC electronic GmbH 2006 L 1020e 12 51 CANopen Software 2 2 Directory Structure Where to find which files Folder Contents Doku CANopen documentation Include This folder contains all interface files for CANopen The files global h cop h must be included in the application CCM Files of the CCM layer COPstack Files of the CANopen stack CDRV Files of the hardware specific layer Objdicts This folder contains predefined object dictionaries for different device profiles Each object dictionary consist of 3 files that belong together objdict c objdict h and obdcfg h These files can be automatically created with the help of the ODBuilder tooll The selection of the object dictionary occurs by defining the applicable include path within the project settings In addition the following subfolders contain the corresponding EDS file and the project file for the ODBuilder DSP401_3P Object dictionary for DSP 401 with 3 RPDOs and 3 TPDOs slave DSP401_7P Object dictionary for DSP 401 with 7 RPDOs and 7 TPDOs slave 0401 Object dictionary for DSP 401 with 3 RPDOs and 3 TPDOs NMT master 0401 7 Object dictionary for DSP 401 with 7 RPDOs and 7 TPDOs DS401_4PST Object dictionary for DSP 401 static PDO mapping
29. decremented after successful communication If the error counter exceeds certain error limits it causes the CAN controller to shut off It then will no longer participate on further communication unless the application resets the CAN controller or its error counter SYS TEC electronic GmbH 2006 L 1020e 12 31 CANopen Software Errors that are caused by improper access to object dictionary entries or interrupted transmission of SDO services will be reported by an abort SDO transfer service message in CANopen 1 2 4 Layer Setting Service LSS In the CiA DSP 305 standard CANopen defines layer setting services LSS to allow configuration of base parameters baud rate node number for devices that do not provide any means of external mechanical configuration e g via DIP or HEX switches The LSS master can change the baud rate and node number of a CANopen LSS slave over the CAN bus with the help of layer setting services LSS First the LSS master renders all LSS slaves into configuration mode Then the LSS master transmits the new baud rate using the Configure Bit Timing service The LSS slave now responds with a CAN message that indicates whether this new baud rate is supported by the LSS slave or not If the LSS slave accepts the new baud rate the LSS master sends the Activate Bit Timing service to the LSS slave This informs the LSS slave to activate the new baud rate after a time called switch_delay After
30. for a producer expires without receipt of a corresponding Heartbeat message then the consumer reports an event to the application The Heartbeat consumer is completely deactivated when the consumer Heartbeat time is given a value of 0 SYS TEC electronic GmbH 2006 L 1020e 12 39 CANopen Software 1 4 CANopen Communication Profile The CiA DS 301 4 CANopen communication profile defines the communication parameter for communication objects that must be supported by each CANopen device for this class Beyond the communication profile supplemental device specific CANopen frameworks and device profiles are available The following CANopen frameworks have been released by the CiA selection Framework for programmable CANopen devices CiA DSP 302 Framework for safety relevant data transmission CiA DSP 304 The following CANopen device profiles are available Device profile for input output modules CiA DSP 401 7 Device profile for drive controls CiA DSP 402 Device profile for display and terminal devices CiA DSP 403 Device profile for sensors and data acquisition modules CiA DSP 404 Device profile for SPS according to IEC 61131 2 CiA DSP 405 Device profile for encoder CiA DSP 406 Device profile for proportional valves CiA DSP 408 CAN identifier of a COB inhibit times and transmission type of a PDO amongst others are considered communication parameters The communication parameters are part
31. has been optimized for access speed and memory space requirements Creation of an Object Dictionary is supported with the help of macros It can be created manually or by help of the ODBuilder tool An entry for a sub index contains the type of the Object Dictionary right of access start value range values and the data pointer In the case of a static Object Dictionary the management structure for the Object Dictionary is created during compilation Modification of the table during runtime is not possible Therefore any later use of an entry must be known about ahead of time In the case of a dynamic OD the management structures of the Object Dictionary are created during runtime The application s variables and fields which are to be transmitted with the help of PDOs or which were declared as DOMAIN or strings have to be registered in the Object Dictionary Var entries The CCM layer makes the function CcmDefineVarTab available for this purpose which automates this procedure with the help of tables e Structures are used for transferring complex parameters to functions The structures are explained as function parameters Prior to a function call a structure of this kind must be initialized Structures and tables for the management of internal cycles and settings For the management of PDOs SDO server SDO client internal tables are used The size of the tables i e number of entries is based on the defined number of PD
32. included with the CANopen Source Code There are functions in these files for initialization of a timer the serial interface as well as for release of the global and CAN controller specific interrupt SYS TEC electronic GmbH 2006 L 1020e 12 71 CANopen Software Examples for the hardware initialization void main void disable global interrupt gtEnableGloballInterrupt FALSE init target timer interrupts TgtInit init general TgtInitSerial init serial interface TgtInitTimer init system time TgtInitCanIsr init CAN controller interrupt enable global interrupt tEnableGloballInterrupt TRUE When using an operating system the hardware is usually initialized by the operating system Functions may be necessary for the initialization of the operating system 2 6 2 2 Initializing the CANopen Layer and Creating the Data Structures Each module in the CANopen stack or Cdrv layer CAN driver CdrvXxx c contains a function for the initialization and parameterization of the module The Init function must be executed for each instance This step is required in order to correctly process additional functions within the module The function CemInitCANopen executes the basic initialization of the CANopen layer The Init functions of the individual modules are called within this function This provides the conditions necessary to link
33. instances the instance parameter must be given CcmConnectToNet HandleInstance0 In the file instdef h macros are defined for the declaration and transmission of instance parameters to functions and for access to entries in an instance tables Use of these macros supports function writes which are independent from the number of instances As a rule the number of instances CANopen interfaces is defined by the application SYS TEC electronic GmbH 2006 L 1020e 12 65 CANopen Software 2 5 1 Using the Instance Handle An instance handle is used as a reference to the current instance if a CCM layer function is called or if one of the application s callback functions is called If multiple instances are used in a CANopen application then the instance macros have the following contents The macro corresponds to in the C Source For declaration of parameters in a function s parameter list CCM_DECL_INSTANCE_HDL tCopInstanceHdl InstanceHandle DECL INSTANCE HDL tCopInstanceHdl InstanceHandle DECL INSTANCE HDL MEM pInstanceHandle DECL INSTANCE HDL tCopInstanceHd MEM pInstanceHandle For handing over parameters to the function to be called CCM INSTANCE HDL InstanceHandle CCM INSTANCE HDL InstanceHandle Table 17 Meaning of instance macros as handle If only one instance is
34. is possible without using one of the CANopen stack s or a pointer s API functions Transmission per SDO or access with the help of API functions is not limited thereby Due to versatility in application and the alterability of these entries they are defined as Var entry variable object entry As mentioned above these Var entries can be embedded in PDOs under the condition that mapping of the entries with the attribute kObdAccPdo is allowed In order to register a fast and simple modification of a variable with the application a variable callback function that includes an argument pointer can be provided when defining Var Entries Modification of an entry over the CAN bus via a PDO results in the call of the respective PDO callback function whereby the argument pointer is given as the parameter The CANopen stack and the hardware drivers are instanceable This means that the functional contents of CANopen can be utilized in several data instances This makes it possible to use various independent CANopen interfaces on the same target e g device with more than one CAN controller 54 SYS TEC electronic GmbH 2006 L 1020e 12 User Layer The Object Dictionary is organized as table Each table entry corresponds to an index This index table is located in the ROM Within an index there are additional tables with an entry for each sub index The sub index table can be stored in either the ROM or the RAM The design of the table
35. of the object dictionary and they can be read from and if the applicable access rights are granted be written to by the user application Some parameters are explained in section 1 2 while information on other parameters can be found in the previously discussed CANopen frameworks and device profiles 40 SYS TEC electronic GmbH 2006 L 1020e 12 Fundamentals 1 5 Transmission Protocols Transmission of communication objects is defined by transmission protocols These protocols are also described in the CiA DS 301 CANopen communication profile and are not a topic of this manual It should be noted however that the range of the realizable protocols can be limited This saves resources for code and data Section 2 11 describes how this resource reduction can be achieved 1 6 Object Dictionary The object dictionary OD is the connecting element between the application and communication on the CAN bus enabling data exchange from the application over the CAN network CANopen defines services and communication objects for accessing the object dictionary Each entry is addressed via index and sub index The properties of an OD entry are defined by a type UINT8 UIN16 REAL32 visible string and attributes read only write only const read write mappable maximum number of OD index entries is 65 536 between 0 and 255 sub index entries are possible for each main index Index entries are pre defined by the applicable com
36. service data objects SDO that are used to access these entries Communication Layer Index Subindex Attributes 0x2000 1 IW 0x2000 ro Data lt gt CANBus 0x6200 0 ro Figure 4 Data transmission of object data via SDO The communication model used for this data exchange is based on the client server structure A read or write access is always initiated by a client and is served by a server Each CANopen device must have an SDO server to access its object dictionary 28 SYS TEC electronic GmbH 2006 L 1020e 12 Fundamentals SDO transmission requires two different COB IDs CAN identifier The first COB ID is used to transmit the request from the client to the server The server sends its response back to the client using the second COB ID Different COB IDs must be used for each direction in order to avoid collisions on the CAN bus The communication profile defines the COB IDs that should be used for the default SDP server Each CANopen device may possess up to 127 SDO servers The CANopen standard CiA DS 301 defines different protocols for transmission of SDOs Protocol Data Length Description expedited transfer 1 4 bytes Data is already transmitted when initiating the data transfer This protocol must be supported by each CANopen device segmented 1 gt 64 kByte Only the length of the upcoming data transfer package i
37. successful completion of this cycle the LSS master renders the LSS slave back into operational mode The LSS service can also be used to change the node address of an LSS slave For this the LSS master renders all LSS slaves into configuration mode again Then the LSS master transmits the new node address The LSS slave now responds with a CAN message that indicates whether this new node number is within the supported range of node numbers for this node Upon switching the LSS slave back into operational mode a software reset is released This causes the LSS slave to configure its communication objects based on the new node number refer to section 1 8 Identifier DLC 0 7 5 0x04 mod reserved Figure 6 Switch Mode Global service mod new LSS mode 0 switch to operational mode 1 switch to configuration mode 32 SYS TEC electronic GmbH 2006 L 1020e 12 Fundamentals Identifier DLC Data Ox7ES 8 0x13 tab reserved Figure 7 Configure Bit Timing service tab indicates the baud rate table to be used baud rate table as defined according to DSP 305 1 127 reserved 128 255 be defined by the user ind index within the baud rate table in which the new baud rate for the CANopen device is stored Identifier DLC 0 7 4 8 0 11 err spec reserved Figure 8 Response to Configure Bit T
38. the SYNC message An event timer can be used to initiate transmission of a PDO after the event time is expired even if the data within the PDO have not changed The event time is configured with the help of sub index 5 SYS TEC electronic GmbH 2006 L 1020e 12 25 CANopen Software Transmission Data requisition Transmit PDO type 0 Data input values are read upon If the PDO data has changed receipt of a SYNC message compared to the previous PDO content then the PDO will be transmitted 1 240 Data is collected and updated upon receipt of the n th number of SYNC messages and then transmitted on the bus The transmission type corresponds to the value of n 241 251 reserved 252 Data input values are read upon The PDO is transmitted upon receipt of a SYNC message request via a remote frame 253 The application continuously collects and updates the input data 254 The application defines the event for data requisition and transmission of a PDO An event that causes transmission of a PDO can be the expiration of the event timer The event timer period is configured with sub index 5 Transmission of a PDO independent from the event and if the event timer was configured always starts a new event timer period 255 The device profile defines the event for data requisition and transmission of the PDO An event that causes transmission of a PDO can be the expiration of the event tim
39. the application variables to the entries in the Object Dictionary and initializes the services and communication objects for the data transfer Thus the functions to be executed are assigned the states within the NMT state machine After the function CemInitCANopen has been executed the CANopen device will be in the NMT state machine s INITIALIZING state Initialisation Initialising 4 Reset Appliction gt gt Reset Communication Pre Operational we Operational Figure 19 state machine according to DS 301 V4 02 76 SYS TEC electronic GmbH 2006 L 1020e 12 User Layer 1 Power on or hardware reset kNmtEvEnterlnitialising 2 automatic change into PRE kNmtEvEnterPreOperational OPERATIONAL state after completion of INITIALISATION 3 6 command kNmtEvEnterOperational Start_Remote_Node 4 7 command Enter_Pre_Operational_Node 5 8 command kNmtEvEnterStopped Stop_Remote_Node 9 10 command kNmtEvResetNode Reset_Node 12 NMT command kNmtEvPreResetCommunication 13 14 Reset_Communication kNmtEvResetCommunication kNmtEvPostResetCommunication 15 automatic change into RESET kNmtEvResetNode APPLICATION state after completion of INITIALIZING 16 automatic change into RESET kNmtEvPreResetCommunication 2 4 kNmtEvResetCommunication
40. used then the instance macros have no content 66 SYS TEC electronic GmbH 2006 L 1020e 12 User Layer 2 5 2 Using Instance Pointers An instance pointer is used as a reference to the current instance if a function from a deeper layer is called i e SdosProcess function call through a function from the CCM module If multiple instances are used in a CANopen application then the instance macros have the following contents The macro corresponds to in the C Source For declaration of parameters in a function s parameter list DECL INSTANCE void pInstance DECL INSTANCE _ void MEM pInstance MCO_DECL_PTR_INSTANCE PTR void MEM MEM plnstancePtr DECL INSTANCE _ void MEM plnstancePtr For handing over parameters to modu le s own function MCO_INSTANCE_PTR pInstance INSTANCE _ pInstance MCO PTR INSTANCE PTR pInstancePtr INSTANCE _ pInstancePtr For handing over parameters to functions not inside the module INSTANCE PARAM par par MCO INSTANCE PARAM par par Table 18 Meaning of Instance Macros as Handle If only one instance is used then the instance macros have no content SYS TEC electronic GmbH 2006 L 1020e 12 67 CANopen Software 2 6 Hints for Creating an Application When using the CANopen layer i
41. which circumstances data are collected e g input values read and a PDO is transmitted For RPDOs the transmission type defines how data received in the PDO is put through to the outputs of the device Transmission can be initiated event driven synchronized or in polling mode a TPDOs A TPDO can be transmitted cyclic or acyclic Cyclic transmission takes place after receipt of a cyclic SYNC message In this case it is unimportant whether input data has has changed or not If the transmission type of a TPDO is set to acyclic the corresponding TPDO is sent only after a certain event occurred Such an event can be the reception of a SYNC message a change of the input data the expiration of an event timer period or a remote frame b RPDOs RPDOs will always be received However data contained in the RPDO will only be put through to the corresponding outputs if certain events occur Such an event can be the reception of a SYNC message or a change of the receipt data compared to the previous RPDO As an option the event timer sub index 5 can be configured as supervision time for any transmission type If a PDO is received outside of the period configured with the event time then the application will be informed see CemCbError Section 2 7 1 8 1 SYNC message is a CAN message without data content and is used to synchronize communication objects of other connected nodes The SYNC producer is responsible for cyclic transmission of
42. 0 64014 read analog input 16 array bit 0 number of analog input var 8 const 4 16 bit 1 4 analogue input var 116 0 0 64024 read analog input 32 array bit 0 number of analog input var 18 const 4 32 bit 1 4 analog input var 132 mapp 0 0 64114 write analog output 16 array bit 0 number of analog var 18 const 4 output 16 bit 1 4 analog output var 116 rw mapp 0 SYS TEC electronic GmbH 2006 L 1020e 12 63 CANopen Software Index Sub Name Object Data Attribute Default index Type Type Value 0 64124 write analog output 32 array bit 0 number of analog var 18 const 4 output 32 bit 1 4 analog output var 132 rw mapp 0 0x64244 analog input interrupt array upper limit integer 0 number of analog var 8 const 4 inputs 1 4 analog input var 132 rw store 0 0x64254 analog input interrupt array lower limit integer 0 number of analog var u8 const 4 inputs 1 4 analog input var 132 rw store 0 Table 16 Object Dictionary for standard I O devices 64 SYS TEC electronic GmbH 2006 L 1020e 12 User Layer 2 5 Instanceability of the CANopen Layer The CANopen stack the CCM module and the hardware drivers are instanceable This means that the function contents of CANopen can be applied to multiple data instances This allows for support of multiple independent CANopen interfaces on one target To generate insta
43. 3 Response to Configure Node ID service 34 state machine for CANopen devices 29 Response of the NMT slave to a Node Guarding remote frame36 Response from the NMT Slave to a Life Guarding remote MaMe eanan a 37 Heartbeat fnes8dBO a 38 Software structure 46 Data exchange between application and object dictionary 57 Sequence of a typical CANopen application 71 state machine according to DS 301 V4 02 76 Additional eti leds 82 Sequence of a CANopen 85 Call sequence for events in the LSS callback function 106 Call Sequence for the callback function CcmCStoreLoadObject for AOD u c pt PTT 135 Blinking cycles according to CiA DR303 3 time in ms 181 equence for events in callback function 202 SDO Server Table peti PS an a at 204 Interfaces for modifying communication parameters of a SDO SETV T Sa cta a ERR EP EN By d 206 SYS TEC electronic GmbH 2006 L 1020e 12 Contents Figure 28 Figure 29 Figure 30 Figure 31 Figure 32 Figure 33 Figure 34 Figure 35 Figure 36 Figure 37 Figure 38 Initiating an SDO download pdt tret et pet 211 SDO
44. 6 Table 87 Table 88 Rejecting the download response by the SDO Client 229 Rejecting an upload segment by the SDO client 230 Selecting the CRC calculation algorithm 230 Parameters of the tSdocInitParam Structure 232 Events Processed by SdocNmtEvent 235 Parameters for the tsdocCbFinishParam Structure 242 PDO Transmission Types and Events for Sending PDOs 249 Events for calling a PDO callback function Receipt 251 Events for calling a PDO callback function Sending 252 OBD module configuration 269 Partitions of the Object 275 Executable instructions to the Object Dictionary 276 CANopen Node e puberes e tont 278 Meaning of the Parameter Structure tObdCbParam 282 Events of the callback function for object access 284 Meaning of the parameter of structure tObdVStringDomain 284 Calculating the number of communication objects 289 Parameters of the tCobParam structure 290 Meaning of the Communication Object T ypes 291 Meaning of the NMT 296 Meaning of the tNmtmSlaveParam structure parameters 303 Meaning of the tN
45. Before bit 0 to 29 can be changed you need to set bit 31 of the COB ID to 1 By doing this the PDO becomes disabled and it is allowed to change the parameters The same procedure has to be followed for changing the transmission type sub index 2 The CANopen standard defines COB IDs default identifier for the first 4 PDOs depending on the node number Predefined Connection Set refer to section 1 8 Communication between slave nodes is only possible via a CANopen master when using these default identifiers This however will result in an increased CAN bus load since data exchange between two slave nodes requires sending the message from the first slave to the master first and from there to the second slave CANopen offers the possibility to adjust the CAN identifier for a given communication object For example the CAN identifier for a TPDO can also be assigned to a RPDO With this it is possible to establish direct communication between two slave nodes without a master node This assignment of CAN identifiers for PDOs is also called PDO linking This PDO linking is described in more detail using the following example Inputs 2 and 3 of device are to be transferred to the outputs 1 and 3 of device Both devices support complete mapping 22 SYS TEC electronic GmbH 2006 L 1020e 12 Fundamentals Device A 0 1000 0 6000 1 0 6000 2 0 6000 3 Device Type Input 1 8 Bit
46. DefineProducerTab supports the creation of a list containing CANopen devices to CcmCbEmccEvent be minitored CcmEmcp c This module supports CcmConfigEmcp configuration of the Emergency CemSenEmergency producer It provides a function to erase the Predefined Error Field CcmClearPreDefinedErrorField CcmCbEmcpEvent CcmHbc c This module defines functions for CcmInitHbc Ine A CcmHbcDefineProducerTab supports the creation of a list containing CANopen devices to CcmCbHbcEvent be monitored CcmCbEmcpEvent CcmHbp c This module supports CcmConfigHbp configuration of the Heartbeat producer Ccm303 c This module defines functions Ccm303InitIndicators needed for indicating the internal states of the CANopen device Two LEDs display the state information according to the CiA303 standard Ccm303ProcessIndicators Ccm303SetRunState Ccm303SetErrorState 50 SYS TEC electronic GmbH 2006 L 1020e 12 User Layer CcmLss c This module provides functions CcmLssmSwitchMode for implementing the LSS master service The module also contains the callback function of the LSS CcmLssmInquireldentity slave service CcmLssmConfigureSlave CcmLssmldentifySlave CcmCbLssmEvent CcmCbLsssEvent Table 15 Layer files This list gives the names of a few important files in the CCM layer The CCM layer contents is expanded constantly and can therefore not be
47. MTS at the same time within one CANopen instance HBP This module provides services for a Heartbeat producer It is possible to have a Heartbeat Producer and a Consumer both existing at the same time in one CANopen instance It is not possible to activate both Heartbeat and Life Guarding at the same time for the given node HBC This module provides services for a Heartbeat Consumer It is possible to have a Heartbeat Producer and a Consumer both existing at the same time in one CANopen instance It is not possible to activate both Heartbeat and Life Guarding at the same time for the given node PDO This module provides services to define and transmit PDOs In addition services for Sync Producer and Consumer are generated here as well PDOSTC This module provides the same services as the PDO module but implements a static PDO mapping SDOS This module provides services to manage SDO Servers and service data objects SDO as well as the protocols for transmission of service data objects as server The supported protocols expedited segmented block are configurable SYS TEC electronic GmbH 2006 L 1020e 12 47 CANopen Software SDOC This module provides services to manage SDO Clients and service data objects SDO as well as the protocols for transmission of service data objects as clients The supported protocols expedited segmented block are configurable LSSSLV This mod
48. Os SDO servers etc refer to section 2 11 The tables are created with the compiler when compiling the Object Dictionary In order to conserve memory resources and processing time individual entries fro the tables are connect directly with the entries of the Object Dictionary The tables are initialized with the initialization function of the relevant module Each module contains a global instance table The instance table contains all of the variables for module The variables are used to store processing states and parameters within a module Except for in the case of the CCM module an instance table is only valid within a module and is therefore When creating the Object Dictionary the data structures for for managing the variables are created but NOT the memory this means the variable or the field for storing the data SYS TEC electronic GmbH 2006 L 1020e 12 55 CANopen Software declared to be static Creation and modification of entries for a table is supported by macros refer to section 2 5 56 SYS TEC electronic GmbH 2006 L 1020e 12 Application CANopen 1 1 S CcmWriteObject BYTE Wite i ObdWriteEntry Parameter Index Subindex CcmReadObject float Fd ObdReadFntry Parameter Index Subindex CcmDefineVarTab 1 1 1 1 Writ Read rite ea ObdDefineVar H 1 1 1 1 Parameter Index Subindex Pointer Size Callback BYTE Define Function Pointer to Callback
49. PdoAddlnstance 254 CemsSignalStaticPdo 180 PdoDefineCallback 257 CemsStoreCheckArchivState 129 PdoDeleteInstance 255 CemTriggerNodeGuard 141 PdoForceAsynPdo 265 CcmUnlockCanopenThreads 381 PdolInit 5 ge 253 123 255 CobGheck 5 2 5 en mes 292 261 CobDetine 289 PdoProcessCheckVar 260 CobProcessRecvQueue 294 262 CobsSend 5 5 nen iem 293 PdosSend nues 258 CobUndefine 291 332 EmccAddlInstance 307 PdoSendSync 264 EmecAddProducerNode 311 PdoSetSyncCallback 264 EmccDeleteInstance 308 315 PdoSignalDynPdo 259 EmccDeleteProducerNode 312 PdoSignalStaticPdo 267 eene 307 2 222222 2 260 EmccNmtEvent uses 308 PdoStaticDefineV arField 267 EmccSetEventCallback 310 SCOCADOLT
50. RE OPERATIONAL35 74 78 80 101 SD 28 SDO Abort 344 SDO Block 230 SDO Block Transfer Protocol 213 230 SDO Callback Function111 116 119 231 239 241 245 247 i n 225 SDO Client Creation 227 SDO Client Table 226 SDO Download Protocol 209 SDO Transfer 207 SDO Upload Protocol 212 SDO BLOCKSIZE DOWNLOAD EP TRU 368 SDO BLOCKSIZE UPLOAD 368 SDO BLOCKTRANSFER 368 SDO CALCULATE CRC 369 SDO CALCUULATE CRC 230 SDO MAX CLIENT IN OBD 233 SDO SEGMENTTRANSFER 228 229 369 SDOC Data Structures 226 SDOC Module 225 SDOC DEFAULT TIMEOUT 370 SDOS zi ence Pi 203 SDOS DEFAULT TIMEOUT 369 Segmented Download 228 Segmented Upload 220 247 Service Data Objects 28 Software Structure 45 static PDO mapping 247 265 367 static PDO Mapping 175 Static PDO mapping 47 STOBPED 5 ens 36 Store Callback Function 128 134 Structure tCcmlnitParam 87 380 351
51. SP 305 34 Table 10 Node state of a CANopen 37 Table 11 Heartbeat consumer 29 Table 12 Structure of an Object Dictionary 41 Table 13 Pre defined Master Slave Connection Set 1 44 Table 14 CANopen Stack structure eese eene enne 48 Table T5 CGEM Layer tiles sik roc OHIO qe OU ON 51 Table 16 Object Dictionary for standard I O devices 64 Table 17 Meaning of instance macros as handle 66 Table 18 Meaning of Instance Macros as Handle 67 Table 19 Guide for selecting the required software modules 69 Table 20 state machine explanation List of events and commands 77 Table 21 Supported communication objects in various NMT states 4 78 Table 22 Parameters of the Structure tCcmInitParam 88 Table 23 Parameters of the structure 94 Table 24 Description of the Argument Pointers Based on the Parameter Error ode pasos a eto OX VO o 101 Table 25 Parameters of the Structure tNmtStateError 102 Table 26 Parameters of the Structure 103 Table 27 Par
52. SYS ELECTRONIC CANopen User Manual Software Manual Edition May 2006 system house for distributed automation CANopen Software In this manual are descriptions for copyrighted products which are not explicitly indicated as such The absence of the trademark and copyright symbols does not infer that a product is not protected Additionally registered patents and trademarks are similarly not expressly indicated in this manual The information in this document has been carefully checked and is believed to be entirely reliable However SYS TEC electronic GmbH assumes no responsibility for any inaccuracies SYS TEC electronic GmbH neither gives any guarantee nor accepts any liability whatsoever for consequential damages resulting from the use of this manual or its associated product SYS TEC electronic GmbH reserves the right to alter the information contained herein without prior notification and accepts no responsibility for any damages which might result Additionally SYS TEC electronic GmbH offers no guarantee nor accepts any liability for damages arising from the improper usage or improper installation of the hardware or software SYS TEC electronic GmbH further reserves the right to alter the layout and or design of the hardware without prior notification and accepts no liability for doing so Copyright 2006 SYS TEC electronic GmbH D 07973 Greiz Thueringen Rights including those of translation reprint br
53. ameters of the structure tLssCbParam 105 Table 28 Description of LSS events 105 SYS TEC electronic GmbH 2006 L 1020e 12 Contents Table 29 Parameters of the tSdocParam Structure 109 Table 30 Parameters of the tSdocTransferParam structure 113 Table 31 Possible SDO transfer status values in tSdocState 116 Table 32 Parameters of the Structure tPdoParam 121 Table 33 Events for the Lifeguard Callback Function 127 Table 34 Assignment of the sub indexes of object 0x1010 in the OD section to DE SAVE easdem EN ema 131 Table 35 Parameters of the structure tObdCbStoreParam 135 Table 36 Tasks of the Callback Function CcmCbStoreLoadObject 136 Table 37 Description of commands 140 Table 38 Master callback function 24 422 143 Table 39 Parameters of structure tEmcParam esses 151 Table 40 Events for callback function CcmCbEmpcEvent 157 Table 41 Parameters of the Structure tHbdProdParam 160 Table 42 Event overview and description for heartbeat consumer 161 Table 43 Return codes for function TgtCavGetAttrib 172 Table 44 Equivalent function for static PDO mapping 176 Table 45 P
54. an object dictionary is the subject of an additional manual L number L 1024 provided by SYS TEC Creation of an object dictionary from an EDS electronic data sheet is supported by the OD Builder refer to manual L 1022 1 7 Error Handling and Reporting Various mechanisms are provided in CANopen to report error events e Emergency object This is a high priority 8 byte message that contains the error information Refer to section 1 2 3 for detailed description Error register This is a 1 byte object dictionary entry at index 0x1001 This entry is provided to report the presence of an error and its type e Pre defined error field This is an error list which is stored in the object dictionary at index 0x1003 This list contains the emergency error code as well as device specific information The structure of this list shows the most recent error at sub index 1 l OD Builder is a product developed by SYS TEC electronic GmbH 42 SYS TEC electronic GmbH 2006 L 1020e 12 Fundamentals 1 8 Telegram Table Predefined Connection Set CANopen defines default IDs CAN identifier for simple network configuration with one master node and up to 127 slave nodes These default COB IDs depend on the service and the node number of the corresponding slave device A function code has been defined for each service The resulting COB ID is based on the function code and the node number COB Identifier CAN Identifier
55. application variables i e for storing process data with the CANopen layer Example for initialization of the CANopen layer In the following example initialization of the CANopen layer of a CANopen device is prepared and executed with an instance The node contains the node number 1 a baud rate of 1 Mbit s is selected The clock speed for the controller is 10 MHz for a CPU frequency of 20 MHz When selecting the baud rate table it is important to be sure that the listed clock frequency refers to the clock frequency of the CAN controller and not the oscillator frequency of the CAN controller or the CPU For microcontrollers with an integrated CAN controller or for stand alone CAN controllers the clock speed can usually be determined by dividing or multiplying the oscillator frequency 72 SYS TEC electronic GmbH 2006 L 1020e 12 User Layer define NODE ID 0x41 Node ID is Ox41 define index to baud rate table for 1 Mbit sec define BAUDRATE kBdilMbaud define the baud rate table for 10MHz CAN controller clock define CDRV BDI TABLE awCdrvBdiTablel0 define base address of CAN controller define CAN BASE OxEFOO An acceptance filtration is not provided Each CAN identifier can receive The parameters are stored in a tCcmInitParam structure declared as const The base address of the CAN controller CAN BASE is entered in the structure tCdrvHwParam A function is defined TgtEnableCanInterruptl th
56. arameter of the tPdoStaticParam structure 178 Table 46 States of the green LED according to DR303 3 181 Table 47 States of the red LED according to DR303 3 182 Table 48 Values for parameter State p of function Ccm303SetRunState184 Table 49 Values for parameter State p of function Ccm303SetErrorState186 Table 50 Configuration settings for LSS master and slave 188 Table 51 Effects of object properties on the SDO transfer 208 Table 52 Denial of SDO download initiation at the SDO server 210 Table 53 Denial of SDO Segment Download at the SDO Server 210 Table 54 Denial of SDO upload initiation at the SDO server 212 Table 55 Denial of an SDO segment download at the SDO server 213 Table 56 Selecting the CRC calculation algorithm 214 Table 57 Parameters of structure tSdosInitParam 216 Table 58 Parameters of structure tSdosParam 227 SYS TEC electronic GmbH 2006 L 1020e 12 CANopen Software Table 59 Table 60 Table 61 Table 62 Table 63 Table 64 Table 65 Table 66 Table 67 Table 68 Table 69 Table 70 Table 71 Table 72 Table 73 Table 74 Table 75 Table 76 Table 77 Table 78 Table 79 Table 80 Table 81 Table 82 Table 83 Table 84 Table 85 Table 8
57. cation object for sending process data Transmit Process Data Object Communication object for receiving process data Receive Process Data Object PDO transmission type This always corresponds to sub index 2 of the PDO communication parameter object index 0 1400 to 0 15 and 0 1800 to Ox 19FF Multiplexed PDO Enables the transmission of process data in an SDO like manner It is possible to transmit data to one multiple devices 414 SYS TEC electronic GmbH 2006 L 1020e 12 Index simultanously without having a PDO for each single object DAM Destination Address Mode MPDO mode where the producer adresses the destination object in the consumer s OD SAM Source Address Mode MPDO mode where the producer gives the address of the source object in the local OD The producer has a Scanner list containing all the objects to be sent The consumers have a corresponding dispatcher list This list connects each producer s source object to a destination object in the consumer s OD SYS TEC electronic GmbH 2006 L 1020e 12 415 CANopen Software References 1 2 3 4 5 6 7 User Manual Software Manual SYS TEC electronic GmbH Dokument Nr L 1020 dieses Handbuch Software Manual SYS TEC electronic GmbH 2004 Dokument Nr L 1023 CANopen Objektverzeichnis Software Manual SYS TEC electronic GmbH 2004 Dokumen
58. client table sasap 226 Interface for changing SDO client parameters 228 Initiating an SDO download 24 229 PDO mapping example of the variables at static PDO mapping266 Calling sequence of events for the object callback funktion during a SDO ACCESS usu mi EO dete malle i e ere 287 Calling sequence of svents for the object callback funktion during an access created from the application 287 Call Sequence of CCM Functions with 5 375 Structure of CANopen Software under Linux 377 Call Sequence of the CCM Functions with Linux 219 CANopen Software Structure under Windows 384 SYS TEC electronic GmbH 2006 L 1020e 12 CANopen Software Table 1 Example for mapping parameters for the first 18 Table 2 Mapping Table before changing the Mapping 20 Table 3 Mapping table after Changing the Mapping 21 Table 4 Communication parameter for the first TPDO 21 Table 5 Structure of a COB ID for 5 22 Table 6 Transmission type for 26 Table 7 Transmission type for RPDOS eese 27 Tables sSDO transtet types 29 Table 9 Baud rate table according to D
59. consumer heartbeat array 24 time 2 4 2 0 number of entries var 18 const 1 5 consumer heartbeat var 132 rw 0 time 0x1017 producer Heartbeat var ul6 rw store 0 time 24 Only present in the ODs for the Master 0401p3m and 0401p7m 60 SYS TEC electronic GmbH 2006 L 1020e 12 User Layer Index Sub Name Object Attribute Default index Type Type Value 0 1018 1dentity object record 0 number of entries var 18 const 4 1 vendor ID var u32 ro Ox3F 2 product code var u32 ro 0 3 revision number var u32 ro 0 0 05 4 serial number var u32 ro 1 0 1280 client SDO parameter record 0 number of entries var 18 const 3 1 COB ID client to var u32 rw store 0 8000 server 0000 2 COB ID server to var u32 rw store 0 8000 client 0000 3 node ID server var u8 rw store 0x00 0 1400 receive PDO parameter record 0 largest sub index var u8 ro 5 supported 1 COB ID used by PDO var u32 rw store 0 8000 0000 2 transfer type var us rw store 255 inhibit time var ul6 rw store 0 5 event timer var ul6 rw store 0 0 14 0 1600 receive PDO mapping record 0 number of mapped var 8 rw store 0 application objects in PDO 1 8 PDO mapping for the var u32 rw store 0 n th application object to be mapped 0 16 25 Only present in ODs for Master 0401p3m 0401p7m
60. d After the configuration of these parameters by the application or the NMT master is completed the NMT service Start_Remote_Node 6 can be used to render the node from PRE OPERATIONAL state into OPERATIONAL state This state change also causes the initial transmission of all TPDOs independently of whether an event for it is present Each subsequent transmission of PDOs then always takes place as a function of an event All CANopen devices also support the Stop_Remote_Node 7 Enter_PRE OPERATIONAL State 8 Reset Node 10 Reset Communication 11 services Reset Node is used to reset the application specific data and the communication parameter of the node The poweron values or values stored in non volatile memory if previously stored are used for reset values The CANopen data structures are loaded with their initial values If the service Reset Communication is used to change the state of a node then communication parameters in the CANopen stack are reset exclusively No communication via PDO and SDO is possible if the device is in STOPPED state Only NMT services Node Guarding Life Guarding as well as Heartbeat are possible in this state 1 3 1 2 Node Guarding Node Guarding represents a means of node supervision that is initiated by the NMT master This service is used to request the node s operational state and to determine whether the node is functioning correctly The NMT master transmits a single Node Guar
61. d MMS CANopen provides the following possibilities for auto configuration of CAN networks easy and unified access to all device parameters cyclic and event driven data transfer device synchronization especially for multi device systems SYS TEC electronic GmbH offers the following products and services to support customers in the design of their CANopen applications Implementation of own CANopen master and slave nodes Independent consultancy Development of hardware and software System integration and certification support CAN CANopen seminars The engineers of SYS TEC electronic GmbH have many years of experience with a variety of CAN applications and participate in the Special Interest Group SiG Programmable Devices and CANopen Safety 16 SYS TEC electronic GmbH 2006 L 1020e 12 Fundamentals 1 2 Communication Objects Communication objects COB are used for transmission of data The communication profile defines the parameters of individual communication objects Depending on the communication objects different transmission types and protocols are available Connection of communication objects over the CAN bus is accomplished via CAN identifiers The recipient of a communication object must have the same COB identifier COB ID CAN identifier as the sender of this message Communication objects for unconfirming protocols PDO Emergency possess one COB identifier COB ID CAN identifier while communicati
62. d message to the slave in the form of a remote frame with the CAN identifier 0x700 plus the node address of the NMT slave As a response to this remote frame the NMT slave sends a CAN message back containing its current NMT state and a one bit that toggles between two subsequent messages Identifier DLC 0 700 Node Address 1 Figure 13 Response of the NMT slave to a Node Guarding remote frame 36 SYS TEC electronic GmbH 2006 L 1020e 12 Fundamentals Status Byte Node State 0x00 BOOTUP 0x04 STOPPED 0x05 OPERATIONAL Ox7F PRE OPERATIONAL Table 10 Node state of a CANopen device Bit 7 of the status byte always starts with a 0 and changes its value after each transmission The application is responsible for actively toggling this bit This ensures that the Node Guard response message from a slave is not just stored in one of the Full CAN channels Thus the NMT master will get the confirmation from the NMT slave node that the application is still running 1 3 1 3 Guarding As an alternative to Node Guarding node supervision can also be performed by Life Guarding services In contrast to the Node Guarding the NMT master cyclically sends a Life Guard message to the slave in the form of a remote frame with the CAN identifier 0x700 plus the node address of the NMT slave As a response to this remote frame the NMT slave sends a CAN message back containing its current NMT state and a one bit
63. e PRE OPERATIONAL In this state communication per SDO is possible Life Guarding Node Guarding or Heartbeat is executed if these services were configured by the application With the help of SDOs communication parameters and mapping parameters can be modified for PDOs over the CAN bus The CANopen device switches to state OPERATIONAL after receipt of the NMT Start_Remote_Node from a NMT Master or after calling the function CcmBootNetwork respectively CcmSendNmtCommand 0x00 kNmtCommStartRemoteNode After the execution of this event the function CemConnectToNet is ended State changes are now initiated upon receipt of NMT commands The processing occurs within the function CcmProcess The function CemProcess must be called in a cyclical loop The more often it is called the more stable the CANopen layer s reactions will be to time events 30 network applications where Master is present changing to OPERATIONAL state can be forced by calling the function NMTExecCommand kNmtCommEnterOperational 82 SYS TEC electronic GmbH 2006 L 1020e 12 User Layer Within the function CemProcess CAN messages are evaluated first and assigned to the corresponding internal CANopen modules If an event occurs that is important for the application then a Callback function will be called Most of these Callback functions are located in the CCM module or are components of the application and can therefore be adapted by the use
64. e amount of supported services and protocols within a module can be further reduced refer to section 2 11 This is particularly interesting if very little code and data memory is available on the target Additional settings must be made in the file CopCfg h The CANopen stack is implemented independently of any specific CAN controller For connection of a CAN controller the specific driver module CdrvXxx c and possibly another module CciXxx c must be included The module is required if a stand alone controller can be connected to a microcontroller in different ways 25 Additional information is available in the manual CAN Drivers L 1023 The baud rate table contains values for various baud rates for the baud rate registers BTRO These values are calculated based on the clock frequency of the CAN controller and not the crystal or oscillator frequency The clock frequency of the CAN controller is usually determined by dividing or multiplying the oscillator frequency of the CAN controller or microcontroller 2 6 2 Sequence of a CANopen application A CANopen application has the following cycle in principle o Initializing the hardware o Creating the data structure Object Dictionary Tables Structures Variables Instances and linking the configured modules configuration of node numbers Initialization of services communication parameters creating communication objects o Processing events and executio
65. e on the CAN bus load Index Sub index Object Data Description 1800h 0 Number on entries 1 COB ID CAN identifier for the PDO 2 Transmission Type transmission type of the PDO 3 Inhibit Time minimum inhibit time for a TPDO 4 reserved reserved 5 Event Time maximum time between two TPDOs Table 4 Communication parameter for the first TPDO PDO communication parameters are entries in the object dictionary for RPDOs index 0x1400 Ox15FF for TPDOs index 0x1800 0x19FF that can be read and if permitted changed via the CAN bus with the help of service data objects SDO SYS TEC electronic GmbH 2006 L 1020e 12 21 CANopen Software 1 2 1 3 COB ID CAN identifier sub index 1 The COB ID serves for identification and definition of the PDO s priority upon bus access Only one sender producer is allowed for each individual CAN message It is however possible that multiple receivers consumers for this message exist Bit 31 130 28 11 11 bit ID 01 01 o 000000000000000000 11 bit identifier 29 bit ID 01 01 d 29 bit identifier Table 5 Structure of a COB ID for PDOs Bit 30 defines the access rights bit 3020 means that a remote transmission request for this PDO is permitted Using bit 31 the PDO can be deactivated for further processing Note Since CiA DS 301 V4 02 a new procedure for changing of the mapping and communication parameters applies
66. er The event timer period is configured with sub index 5 Transmission of a PDO independent from the event and if the event timer was configured always starts a new event timer period Table 6 Transmission type for TPDOs 26 SYS TEC electronic GmbH 2006 L 1020e 12 Fundamentals Trans mission PDO receipt Data update type 0 The PDO will always be Data is analyzed upon receipt of a receipt Analysis and if SYNC message If the data has required update of the data changed compared to the previous occurs upon receipt of the next RPDO then it will be updated on the valid SYNC message outputs Transmission of the SYNC message is acyclic 1 240 Data is analyzed upon receipt of the n th number of SYNC messages If the data has changed compared to the previous RPDO then they will be updated on the outputs The transmission type corresponds to the value of n Transmission of the SYNC message is cyclic 241 251 reserved 252 reserved 253 254 The PDO will always be The application defines the event for receipt updating the output data 255 The PDO will always be The device profile defines the event receipt for updating the output data Table 7 Transmission type for RPDOs 1 2 1 5 Minimum Inhibit Time Sub index 3 The inhibit time represents the minimum time that must elapse between transmission of two TPDOs This enables a reduction of the bus load and an i
67. er Emcp c Mandatory module Emergency consumer Emcp c optional Life Guarding Master Nmtm c The module Nmtm c Life Guarding Slave Nmts c ane raise should always be used in an Node Guarding Master Nmtm c either or fashion Node Guarding Slave Nmts c LSS Slave LssSlv c optional LSS Master LssMst c optional Creating communication objects for Cob c Mandatory module message transmission Functions for access to the object entries Obd c Mandatory module NMT state machine Nmt c Mandatory module Functions for accessing machine Mandatory module specific data formats for the given microcontroller Xxx Driver for the applicable CAN CdrvXxx c Mandatory module controller Xxx or operating system Interface functions for adapting the CciXxx c Mandatory module hardware specific CAN controller connections Baud rate table containing the supported BdiTabXxx c Mandatory module Table 19 Guide for selecting the required software modules SYS TEC electronic GmbH 2006 L 1020e 12 69 CANopen Software Modules in the CCM layer are optional except for module CemMain c modules support the user during configuration of the application The user has to decide which modules to include An Emergency producer is always supported even if this service is optional according to the standard CiA DS 301 However practical application has shown that for diagnosis of an error in an application this service must be used Th
68. etation of these data is defined in the application profile respectively the device profiles Device profiles are available for different device classes such as I O modules CiA DSP 401 drives CIA DSP 402 and human machine interfaces HMI CiA DSP 403 standardization of device specific data interpretation allows the building of partially exchangeable devices Each CANopen device features an Object Dictionary OD as the main data structure The Object Dictionary serves as the primary data exchange medium between the application and the CAN bus communication Access to the OD entries is possible from both sides from the application as well as from the CAN bus via specific messages These OD entries can be considered as variables or fields from the programmer s point of view Each entry in the Object Dictionary has an index and a sub index assigned to it Using this index structure it is possible to clearly address an OD entry The CANopen stack provides API functions to define entries in the Object Dictionary as well as to read or write these entries With the help of communication objects it is also possible to access the Object Dictionary over the CAN bus Properties have to be defined for each entry in the Object Dictionary These properties include the data type UNSIGNEDS and various attributes such as the access rights read only write only the transmission of the data in a PDO or supervision of the value range via its
69. etie 30 1228 TEST TIC Voss tacet RU 30 1 2 4 Layer Setting Service LSS entend 22 1 3 Network Management 000000000000000 00000000 00000000000000 00000000000000 tease 35 1 4 CANopen Communication Profile 0o000000000000000000 0000000000000000 40 1 5 Transmission Protocols cicccssssccceccsscecsscscessssecisevensssnesonssesenssecees 41 1 6 Object Dictionary 41 1 7 Error Handling and Reporting e eese 0000000000000000 42 1 8 Telegram Table Predefined Connection Set 43 2 CANopen User 45 2 1 Software S GUClure une eet 45 211 CANopen Stack asa aa aa an p ti i TH EP rt pd 47 2 1 2 Hardware Specific Layer esses 48 21 3 CCM Application specific 40 2 2 Directory 52 2 3 Data Structures ooo0000000000000000 0000000000000000 0000000000000000 anana 0nnne 54 Z4 Object DICUODAEy 58 2 4 1 Object Dictionary for Standard I O Devices 29 2 5 Instanceability of the CANopen Layer eee eene 65 2 5 1 Using the Instance Handle det 66 2 5 2 Using Instance irte o tene ipte en 67 2 6 Hint
70. h to receive a complete copy of this document please contact us via e mail support systec electronic com CANopen Software 4 Notes on CANopen Certification For CANopen certification with CiA the following should be noted Only a device can be certified and not software The CANopen stack was certified with the CANopen Chip from SYS TEC electronic GmbH Certificate No CiA200002 301V30 1 1 013 Thus we can demonstrate that certification with our CANopen stack is possible However certification also depends on a number of factors that we cannot influence directly Therefore please note the following The entries in the OD must match those in the EDS file This effects above all the device name Index 0x1008 the hardware and software version Index 0x1009 or 0x1004A etc The number of PDOs must match the PDOs actually present in the OD All indices that are present in the software must also be entered in the EDS file There can be no hidden entries The entries in Index 0 100 and 0x100D Life Guarding must have a default setting of zero The Index 0x1003 Sub index 0 can only be written to with a 0 and then the error field has to be erased Writing a number that is greater than O will result in an error The Mapping Parameter Sub indexes 0 e g 0x1600 0 0x1601 0 0x1 A00 0 etc can be written with values up to 64 max If the maximum value is exceed an error message will result Since our CANopen software suppor
71. ication In order to guarantee an error free compilation the path must be defined to point to the include folder and the Object Dictionary for the compiler or for the IDE project SYS TEC electronic GmbH 2006 L 1020e 12 53 CANopen Software 2 3 Data Structures In the following section there are explanations for the data structures There are data structures that are used for data exchange between the application and CANopen Other data structures are used for management and control of processing cycles functions or protocols within a module and are only mentioned to provide a complete listing The following data structures are used as application interfaces Each CANopen instance has its own Object Dictionary OD The Object Dictionary is the coupling element between the application the communication layer and contains all CANopen device data Entries in the Object Dictionary are addressed over index and sub index Entries can be read or written over the CAN bus with the help of service data objects SDO refer to section 1 2 2 or through the application with the help of API functions refer to sections 2 7 4 and 2 8 5 With the help of the OBD module s API functions the address and size of an entry can be determined whereby access to the object entry data is possible via pointers refer to section 2 8 5 OD entries can also be linked with application fields or variables This is advantageous in that access to data
72. iming service err error code 0 operation completed successfully 1 baud rate not supported 2 254 reserved 255 special error code in spec spec manufacturer specific error code only if err 255 Identifier DLC Data 2 e s reserved 0 7 5 8 0 15 delay Figure 9 Activate Bit Timing service delay relative time until activating new baud rate in ms Identifier DLC Data L pog 08 088 0 7 5 8 0 11 nid Figure 10 Configure Node ID service reserved nid new node address for the LSS slave values permitted 1 to 127 SYS TEC electronic GmbH 2006 L 1020e 12 33 CANopen Software Identifier DLC Data 0 1 2 3 4 5 0 7 4 8 0 13 spec Figure 11 Response to Configure Node ID service reserved err error code 0 operation completed successfully 1 node address invalid only values 1 to 127 are permitted 2 254 reserved 255 special error code in spec spec manufacturer specific error code only if err 255 Table Index Baud Rate SYSTEC Definition in cdrv h 0 1000 kBit s kBdil Mbaud 1 800 kBit s kBdi800kBaud 2 500 kBit s kBdi500kBaud 3 250 kBit s kBdi250kBaud 4 125 kBit s kbdil25kBaud 5 100 kBit s kBdil00kBaud 6 50 kBit s kBdi50kBaud 7 20 kBit s kBdi20kBaud 8 10 kBit s kBdilOkBaud Table 9 Baud rate table according to CiA DSP 305
73. ionary Configuration 371 up 405 OD for I O 1 59 Master callback function 137 Operating Systems 372 Master Callback Function137 141 OPERATIONAL 36 82 142 301 306 irasan 17 247 353 Motorola 408 Event Time 365 MPDO 331 414 PDO Callback Functionl21 250 Network Management 35 258 NMT PDO Configuration 80 120 OPERATIONAL ee ea 278 PDO 102 SYS TEC electronic GmbH 2006 L 1020e 12 425 CANopen Software PDO Event Time 250 PDO Inhibit Time 250 PDO Initialization 253 PDO Linking 18 82 120 PDO Mapping 18 82 120 PDO 247 PDO Receive Notification 250 PDO Remote Frame 366 PDO Send Notification 250 PDO Synchronization 145 147 263 PDO Transfer 250 260 261 262 PDO Transmission 18 258 PDO USE EVENT TIMER 365 PDO USE MPDO DAM CONSU PDO USE REMOTE PDOS 366 PDO USE STATIC MAPPING 367 PDO USE SYNC PDOS 365 PDO USE SYNC PRODUCER 366 PROS TC d eut due didi 47 247 OPERATIONAL 90 92 Pre Defined Connection Set 35 P
74. ithout complications there can be no lateral function call to another module within the modularized software layer rather only to modules positioned above or below as a Callback function The application specific layer CANopen controlling CCM Module controls the interaction of the individual modules The CCM layer is not absolutely necessary for implementation in the application However it provides a convenient interface for use of multiple CANopen instances and encapsulates sequential function calls of multiple API functions i e initialization definition of PDOs in functions The hardware specific layer encapsulates the special properties of a CAN controller or microcontroller Porting to new hardware is simplified thereby and can be reduced to an exchange of the transceiver for the CAN controller and the microcontroller specific initialization 1 With this it is possible to not include certain modules or services when creating a CANopen application without getting error messages from the linker about unreferenced functions SYS TEC electronic GmbH 2006 L 1020e 12 45 90001 1 9007 HAWD 211045312 DAL SAS 9r g 24n814 121 415 M2144240 JOAN Applikation CCM CCMXxx CCMMain
75. limiting values The application layer and the communication profile are thoroughly described by the CiA DS301 specification Use of CANopen frameworks extensions of this standard is described for specific applications These frameworks define further rules as well as specific communication objects For example the CiA 05301 defines network management objects Node Guarding Life Use of these objects for supervision of CANopen devices is described by the framework The following CANopen frameworks are available Framework for programmable CANopen devices CiA DSP 302 Framework for safety relevant data transmission CiA DSP 304 l Definition of the API functions is manufacturer specific Entries can be mapped into a PDO for transmission as process data object 3 Only such values are written to an entry if they are within the limiting value ranges other values will not be accepted SYS TEC electronic GmbH 2006 L 1020e 12 15 CANopen Software Summary of advantages using CANopen vendor independent standards open structure real time communication for process data without protocol overhead modular scalable structure that can be tailored to the needs of the user within a wide range of networked automation control systems comprehensive functionality for communication and network supervision tasks support of system integrators by configuration and supervision tools profiles oriented on Interbus S Profibus an
76. mtmSlavelInfo structure parameters 305 Parameters of structure tMPdoParam 333 SDO saa naa aa Ada an a aga 345 Emergency Error Codes according to 4 347 Additional Parameters of the Structure tCcmInitParam for Implementation of Multiple CAN Drivers 350 Function Prefix for the CAN Driver seen 352 Properties for Executing Process Functions 362 Setting Time Monitoring for the PDO Module 364 Additional Parameters in the Structure tCcmInitParam 374 SYS TEC electronic GmbH 2006 L 1020e 12 Contents Table 89 Table 90 Table 91 Table 92 Table 93 Table 94 Table 95 Table 96 Table 97 CCM Thread Events under Linux 382 Module Configuration of CANOPMA DLL and d ont ined nune 384 Module Configuration of CCMMA DLL and CCMSL DLL 385 Thread Evemts for CANopen under Windows 395 Memory Type Definition for Various Target Systems 401 List of Currently Available CAN 403 Bit Rate Configuration File Overview esses 404 List of Application Specific 405 List of Target Specific Functions 4
77. munication profile or device profile respectively Type and attributes for available sub index entries within a main index may vary Index Sub index Type Attribute 0x2000 0 UINTS8 const 1 UINT32 read write 2 3 Table 12 Structure of an Object Dictionary entry Default values can be assigned to individual entries The value of an entry can be changed with the help of SDO communication if the attribute assigned to the entry allows such access read write and write only not possible for read only and const The value can also be changed by the application itself it the attributes for the entry are read write write only and read only not possible for const The OD is further divided in sections The section with index 0x 1000 0x1 FFF is used for definition of parameters for the communication objects and the storage of common information such as manufacturer name device type serial number etc Entries from index 0x2000 to OxSFFF are reserved for storing manufacturer specific values Device specific entries as defined by the device profile or frameworks follow at index 0x6000 and higher SYS TEC electronic GmbH 2006 L 1020e 12 41 CANopen Software CiA DS 301 defines several mandatory entries that each CANopen device must always possess These entries are marked as mandatory These mandatory entries are supplemented by entries defined in the corresponding device profile The creation of
78. n wo write only only a write to the object is possible per SDO or from the application const constant object can only be read and not written per SDO or from the application mapp object can be mapped to a PDO store object can be saved in non volatile memory refer to section 2 7 6 58 SYS TEC electronic GmbH 2006 L 1020e 12 User Layer 2 41 Object Dictionary for Standard I O Devices There are several Object Dictionaries available for standard I O devices The OD ds401_3p contains 3 TPDOs and 3 RPDOs the OD ds401_7p contains 7 TPDOs and 7 RPDOs Otherwise the two Object Dictionaries are the same in terms of all other objects The OD 0401p3m has 3 TPDOs and 3 RPDOs but as a CANopen Master it does not contain the objects 0 100 and Ox100D Instead it contains the supplemental objects 0x1016 for the Heartbeat Consumer and 0x1280 for the first SDO Client O401p7m resembles o401p3m except that it has 7 TPDOs and 7 RPDOs CANopen Kits have two ODs available to them 0401p2ks for the Slave and o401p2km for the Master Both of these contain only 2 TPDOs and 2 RPDOs and the Master is not equipped with a Heartbeat Consumer Object 0 1016 is absent Index Sub Name Object Attribute Default index Type Type Value 0x 1000 device type var u32 ro 0x000F 0191 0x1001 error register var 8 0 0 1003 predefined error field 0 number of errors var u8 IW 0
79. n of service demands from the application Closing the CANopen layer if necessary 28 Connection to an INTEL 82C527 CAN controller can be achieved via both serial or parallel interface 70 SYS TEC electronic GmbH 2006 L 1020e 12 User Layer 12 Initializing the hardware _ s Initializing the CANopen layer Initializing the services and communication objects Processing of events in the CANopen layer Processing of service requests from the application Shutting down CANopen layer Terminating services and closing communication objects Figure 18 Sequence of a typical CANopen application 2 6 2 1 Initializing the Hardware Before the CANopen layer is initialized the hardware must be initialized by the application To function correctly the CANopen requires a time basis generated in l00us as well as an interface in the debug version for the output of error messages If an error is discovered based on a faulty configuration or parameterization then the CANopen layer will call standard C function printf in some cases The output of the serial data stream to a terminal may need to be adapter for the target The global interrupt of the microcontroller is to be released and the CAN controller s service routine included which involves setting the interrupt vector and the interrupt priority Upon delivery target c files for various target platforms are
80. n the mapping table Note Before performing a new mapping the user must ensure that sub index 0 of this mapping entry contains the value 0 If this is not the case the SDO abort code 0x06010000 unsupported object access is returned upon an attempt to remap With the help of a SDO download the new configuration can be stored in the mapping table The new configuration becomes valid after writing the value 4 to sub index 0 in the mapping table l Deactivating the current configuration causes all mapping parameter to become invalid and they will be erased 20 SYS TEC electronic GmbH 2006 L 1020e 12 Fundamentals Index Sub Object Data Description index 0 1 00 0 4 Number of mapped entries 1 0x20000310 UNSIGEND 16 at index 0x2000 sub index 3 2 0x20000108 UNSIGEND8 at index 0x2000 sub index 1 3 0x20000208 UNSIGEND S at index 0x2000 sub index 2 4 0 20000610 UNSIGNED106 at index 0x2000 sub index 6 Table 3 Mapping table after Changing the Mapping The resulting length of the CAN massage for transmission of this PDO is now 6 bytes 1 2 1 2 Communication parameter Which transmission types are available for PDO The communication parameters define the transmission properties and the COB IB CAN identifier for transmission of a PDO Configuration of the communication parameters has a direct impact on the frequency of PDO transmissions and henc
81. nal 278 290 kNodeStatePreOperational 278 424 SYS TEC electronic GmbH 2006 L 1020e 12 kNodesStateStopped 278 kObdAceVar 2T kObdDirlnit 276 kObdDirLoad 276 kObdDirRestore 276 276 kObdEvAbortSdo 284 kObdEvCheckExist 283 kObdEVviInitWrite 283 kObdEvPostRead 283 kObdEvPostWrite 283 kObdEvPreRead 283 kObdEvPreWirite 283 kObdEvWiStringDomain 284 kObdPartAll 275 275 275 kObdPartMan 275 5 275 Konstante kLssmEvTimeout 200 Layer Setting Service 32 Lgs Callback Function 125 127 298 Life Guarding 36 37 Linux sec en Eee 376 Little Endian 408 32 LSS address 190 194 LSS Callback Function 104 LSS master 32
82. nces all global and static variables are stored in so called instance tables Each table entry corresponds exactly to a CANopen instance An entry is described by a structure When called the functions receive a reference to the instance to be processed in the form of an instance pointer or an instance handle The number of instances and thereby the number of entries in an instance table are defined as constants during compilation These constants are called COP_MAX_INSTANCES for the CANopen and are defined in the file copefg h There is a separate define called CDRV MAX INSTANCES for instancing the CAN drivers which is also defined in the file refer to section 2 11 1 Access to the structure elements of an instance occurs exclusively via macros When defining multiple instances if a function call occurs a reference to the instance to be processed is always given as a parameter in the form of an address to an instance table refer to section 2 5 2 or instance handle refer to section 2 5 1 If only one instance was defined then this parameter is left out In the description of the API functions this parameter will always be listed The definition of the instance parameter is given with the help of macros These macros are deleted by the compilers preprocessor depending on the defined number of instances Example If only one instance is used then the following instance parameter should be removed CcmConnectToNet For multiple
83. ncrease in data bandwidth The inhibit time is stored as UNSIGNED 16 value in steps of 100 us SYS TEC electronic GmbH 2006 L 1020e 12 27 CANopen Software 1 2 1 6 Event Time Sub index 5 a TPDOs After the event time has expired a TPDO is sent even if the data content of the PDO has not changed compared to the previous transmission The event timer is restarted after each transmission Hereby it is unimportant whether the transmission was caused by the expiration of the event time or the change of the PDO data This allows configuration of periodic PDO transmission An inhibit time configured via sub index 3 will not be considered Resetting the event time to zero zero is the default value results in deactivation of the event timer Transmission of the PDO is then only possible if the data content changes The inhibit time will be considered in this case b RPDO The event timer sub index 5 can be configured as supervision time if the transmission type 254 or 255 is selected If no PDO is received within the period configured with the event time then the application will be informed 1 23 20 SDO Service Data Objects The Object Dictionary serves as primary data exchange medium between the application layer and the communication layer data entries for a CANopen device can be managed within the Object Dictionary OD Each OD entry can be addressed using index and sub index CANopen defines so called
84. ng parameters is described in the example below l Dynamical mapping requires that the modified mapping parameters are stored on a non volatile memory on the target device If this is not possible no non volatile memory available the system configurator must restore the mapping upon network bootup SYS TEC electronic GmbH 2006 L 1020e 12 19 CANopen Software Example of changing the mapping parameters for a TPDO Entries of the object dictionary are mapped into the first TPDO in the following order and length Index 0x2000 Index 0x2000 Index 0x2000 Index 0x6000 sub index 3 sub index 1 sub index 2 sub index 6 length 16 bit length 8 bit length 8 bit length 32 bit Index _ Sub index Object Data Description 0x1A00 0 4 Number of mapped entries 1 0x20000310 UNSIGEND16 at index 0x2000 sub index 3 2 0x20000108 UNSIGENDS at index 0x2000 sub index 1 3 0x20000208 UNSIGENDS at index 0x2000 sub index 2 4 0x60000620 REAL32 at index 0x6000 sub index 6 Table 2 Mapping Table before changing the Mapping The resulting length of the CAN massage for transmission of this PDO is 8 bytes Now instead of transmitting the entry at index 0x6000 sub index 6 the index entry 0x2000 sub index 4 with a length of 16 bits is to be transmitted Before changing the mapping parameters the current configuration must be deactivated This is done by writing the value 0 to sub index O i
85. oadcast photomechanical or similar reproduction and storage or processing in computer systems in whole or in part are reserved No reproduction may occur without the express written consent from SYS TEC electronic GmbH EUROPE NORTH AMERICA SYS TEC electronic GmbH PHYTEC America LLC Address August Bebel Str 29 203 Parfitt Way SW Suite G100 D 07973 Greiz Bainbridge Island WA 98110 GERMANY USA 49 3661 6279 0 1 800 278 9913 Ordering sales systec electronic com info phytec com Information 49 3661 6279 0 1 800 278 9913 Technical support systec electronic com support phytec com Support 449 3661 6279 99 1 206 780 9135 Fax http www systec electronic com http www phytec com Web Site i 4 di 12 Edition May 2006 SYS TEC electronic GmbH 2006 L 1020e 12 Contents Table of Contents me a YE EE 11 1 CANopen 5 1 000000000000 13 1 1 222540404625 ep eaae 14 1 2 Communication 1 000000000 17 1 2 1 PDO Process Data Objects prat i 17 1 2 2 SDO Service Data 28 1 2 1 Synchronization 30 12 2 Tim Object sasasi satang enda nanang
86. ob e p Qoae odia as 346 2 11 Configuration and 2 348 SYS electronic GmbH 2006 L 1020e 12 Contents 2 11 1 Configuration of the CANopen 348 2 11 2 Configuration of the Object 371 2 12 Characteristics of Hardware Operating Systems and Development Environments 00e0000000000 00000000000000 00000000000000 00000o 372 2 12 1 Selecting the Address Space for Data Storage 372 2 12 2 Operating System PxROS eot er et ese 372 2 12 3 Linux Operating RR 376 2 12 4 Windows Operating 383 Hints for Porting to Other Target Platforms 398 3 1 Global Definition File GLOBAL H eere tenen 399 3 2 Selecting the CAN Driver ooooo00000000000 000000 00000000000000 00000000000000 402 3 3 CAN Bit Rate Definition 0000000000000000000 000000000000 00000000000000 404 3 4 Target Specific Settings 0000000000000000 000000 00000000000000 000000000000 405 3 4 1 Hardware Properties Definition sese 405 3 4 2 Memory Management Definition Standard Functions 405 3 4 3 Definition of Target Specific Functions 406 3 5 CPU Variable Byte Order Definition Big Endian Little DP e c 408
87. of a variable that is represented by this PDO expiration of a time or receipt of a certain message Process data is transmitted without protocol overhead directly in a single CAN message The length of a PDO can be between 0 to 8 data bytes PDOs are described by their mapping parameters and their communication parameters The maximum number of TPDOs as well as RPDOs that can be defined is 512 A simple CANopen device typically supports 4 PDOs The actual number of PDOs is defined by the application or by the device profile for a specific CANopen device 12 1 4 Mapping Parameters What is the structure of a PDO A PDO consists of adjacent entries in the object dictionary The so called mapping parameters define the connection to these entries A mapping parameter defines the source of the data via index sub index and number of bits The destination i e the placement within a CAN message is defined by the order of the mapping parameters in the mapping table as well as the number of bits for each data Example Index Sub index Object Data Description 0x1A00 0 4 Number of mapped entries 1 0x20000310 entry at index 0x2000 sub index 3 with a length of 16 bit is mapped to bytes 0 and 1 within the CAN message 2 0x20000108 entry at index 0x2000 sub index 1 with a length of 8 bit is mapped to byte 2 within the CAN message Table 1 Example for mapping parameters for the firs
88. on objects for confirming protocols SDO possess two COB identifiers one identifier each direction 1 2 1 PDO Process Data Objects Process data objects PDO are especially suited for fast transmission of process data The communication model for PDOs defines one PDO producer and one or multiple PDO consumers PDO Consumerl1 PDO Consumer2 PDO Producer PDO Consumer3 PDO Consumer4 Figure 2 Communication model for PDOs CANopen defines different communication objects that are specifically tailored to various tasks and requirements For example process data are transmitted without protocol overhead in a single CAN message Service data objects use additional security mechanisms for supervision of the data transfer between two nodes The data contents of such an SDO object can be transmitted via multiple CAN messages SYS TEC electronic GmbH 2006 L 1020e 12 17 CANopen Software The reception of a PDO is not acknowledged by the PDO consumer The PDO producer transmits a PDO such PDOs are called transmit PDOs TPDOs The PDO consumer receives a PDO consequently such PDOs are called receive PDOs RPDOs Successful reception of a PDO is not acknowledged Multiple PDO consumers may exist for one PDO producer A PDO producer is assigned to one or multiple PDO consumers with the help of its COB ID This is also called PDO linking Transmission of a PDO is triggered by an event Such events can be the change
89. pen device various CANopen functions and properties are required for object entries When you acquire a CANopen Library the parameter of supported services is defined and cannot be modified However when integrating the CANopen Code the selection of services is configurable and can be adapted to application requirements Services are encapsulated in the modules within the CANopen stack The following overview shows which module is required by the respective CANopen service When using the source code the required modules must be referenced during code generation and the appropriate settings made in file CopCfg h refer to section 2 11 Modules that are listed as base modules always have to be referenced during code generation Optional modules can be left out if the service they support is not required 27 When using the debug version various verification tests are performed and in case of an error the corresponding PRINTF output will be generated 68 SYS TEC electronic GmbH 2006 L 1020e 12 User Layer baud rates Service Function Module Category Initializing CANopen CcmMain c Mandatory module Managing of PDOs Pdo c or optional PdoStc c SDO Server SdosComm c Mandatory module SDO Client Sdoc c optional CRC calculation for SDO block transfer SdoCrc c optional Heartbeat producer Hbp c optional Heartbeat consumer Hbc c optional Emergency produc
90. r Furthermore the function CcmProcess tests a few time cycles for which a CAN message may have to be sent under certain circumstances For example PDOs may be sent following completion of the Event Timer Likewise an SDO abort is sent if the SDO server expects a message from the SDO client during a segmented transfer but does not receive one State OPERATIONAL The transmission from PRE OPERATIONAL to OPERATIONAL state generates a transfer of all asynchronous TPDOs In this state PDOs are transferred if an event occurs such as EventTimer expired SYNC message received modification of process variables If PDOs are received then their data is put into the OD and the application will be notified by calling the corresponding callback function containing applicable parameters State STOPPED In this state the execution of all services is stopped with the exception of NMT services this also includes Node Guarding and Heartbeat 2 6 2 5 Shutting Down a CANopen Application The CANopen application is closed executing the function CcmShutDownCANopen This function calls the function XxxDeleteInstance for each module that is configured in the CANopen stack The modules finish their services and delete the communication objects The data structures of the CANopen layer are invalid after the function CcmShutDownCANopen has been executed SYS TEC electronic GmbH 2006 L 1020e 12 83 This document has been truncated If you wis
91. rough the application which inhibits or releases the CAN controller interrupt A Callback function AppCbNmtEvent is defined for processing the state changes of the state machine The function ObdInitRam for initialization of the internal data structures always has to be entered CONST tCcmInitParam ROM CcmInitDefaultParam g NODE_ID node id BAUDRATE index to baud rate CDRV_BDI_TABLE baud rate table OxFFFFFFFFL Acceptance Mask Register 0 000000001 Acceptance Code Register O CAN controller address TgtEnableCanInterruptl function pointer to enable CAN interrupt AppCbNmtEvent pointer to NMT Callback function ObdInitRam init function for OD this example all entries for the structure are fixed and cannot be changed during runtime Therefore the structure is stored in the ROM If the node address or baud rate has to be changed or configured with a DIP switch during runtime then the structure must be stored in RAM so that the entries m_bInitNodeld m_BaudIndex etc can be modified by the application By calling the function CcmInitCANopen the CANopen layer is initialized The first call of CcmlnitCANopen is always performed with the parameter kCcmFirstInstance This causes the function to delete the internal instance table The Object Dictionary is created the entries initialized with default values default values can be provided when the Object Dic
92. ruction etc The fundamental communications mechanisms are described in so called Communication Profiles Frameworks complement the communication profile for specific applications This is how frameworks are defined for safety compliant data transfer CANopen Safety or for programmable devices e g PLCs The so called object directory is the central element of every CANopen device and describes the device s functionality l CAN in Automation e V Founded in March 1992 CiA provides technical product and marketing information with the aim of fostering Controller Area Network s image and providing a path for future developments of the CAN protocol SYS TEC electronic GmbH 2006 L 1020e 12 13 CANopen Software 1 1 What is CANopen CANopen defines the application layer a communication profile as well as various application profiles Device Profile Device Profile Module Drives bd Application Profile CiA DSP 401 CiA DSP 402 Application Layer CANopen API CiA DS 301 Framework Object Dictionary CiA DSP 302 CiA DSP 304 Communication Profile Communication Objects CiA DS 301 Framework IPDO DO SYNC mergency CiA DSP 302 E Ese CiA DSP 304 Bus Figure 1 Overview of the CANopen concept The application layer provides confirmed and unconfirmed services to the application and defines the communication objects Services are
93. ry The user is supported thereby by module CcmStore c 80 SYS TEC electronic GmbH 2006 L 1020e 12 User Layer Example tCopKernel PUBLIC AppCbNmtEvent tNmtEvent NmtEvent p tCopKernel Ret kCopSuccessful which event is called switch NmtEvent_p reset all communication objects 0 1000 0 case kNmtEvResetCommunication Ret CcmDefinePdoTab tPdoParam GENERIC amp aPdoTab g 0 sizeof aPdoTab g sizeof tPdoParam break Dissenting from the NMT state machine in Initialisation Initialising Reset Appliction Reset Communication Pre Operational 2 Operational Figure 19 two additional states were implemented within this state SYS TEC electronic GmbH 2006 L 1020e 12 81 CANopen Software kNmtEvPreResetCommunication Shuting down active services Erasing communication objects kNmtEvResetCommunication Initializing communication objects kNmtEvPostResetCommunication Transmitting the BOOTUP message Figure 20 Additional states In the state PRE RESET COMMUNICATION all active services are ended and the communication object is deleted In the state POST RESET COMMUNICATION the transfer of the BOOTUP message is initiated whereby a CANopen slave signals that the initialization is complete The state machine changes to PRE OPERATIONAL state Stat
94. s for Creating an Application 1 68 2 6 1 Selecting the Required Modules and Configuration 68 2 6 2 Sequence of a CANopen 70 2 7 Layer Functions 6se00000000000 00000000000000 00000000000000 0000000000000000 84 2 7 1 Modules 5 Haben Na 84 SYS electronic GmbH 2006 L 1020e 12 CANopen Software 212 CIS COG Ng 107 2 7 3 CembDiPdo Module 119 Ce dr PEE tet a ga E Red 122 2 1 Combos Mod le das ie ethos PER te t Feo ngan PER NER 125 2 1 6 aa ak paeka etri urge te d 128 2 7 7 CembNmitm MOodUIe iret t qma edet 137 2 L8 ComsnPdo Module nana puc rede ar 144 NIOUUIG ea dre aeter oai 144 2 T AOC CME IMCS Module seit rab rS Erit 147 Zu DC ombamnep 151 2 1 12 CcemHbe eco ota ce 158 2 1 1 SCRE Dp Mod le ves nde dau aga vanas eee ea 162 2 WAS TetCav Module d Ga PN 162 2715 ComBOut Modul 6 sasa eaaa aa Duke teorica 173 2 1 16 ombloat Module nera dort qe 174 2 I LED CM SIP dO Module ed utet 175 2 7 ROA CIN OS Module
95. s transmitted when initiating the data transfer Data is transmitted in segments of 7 data bytes and one protocol byte each Each segment is confirmed by a response message block transfer 1 gt 64 kByte Only the length of the upcoming data package is transmitted when initiating the data transfer Data is transmitted in segments of 7 data bytes and one protocol byte each Up to 127 segments are transmitted within one block Only complete blocks are confirmed by a response message Lack of confirmation for each segment increases the data throughput on the bus especially when transmitting larger data packages Table 8 SDO transfer types Reading of OD entries is called upload writing of entries is called download An ongoing transmission can be terminated by a server or a client with the help of the abort transfer service SYS TEC electronic GmbH 2006 L 1020e 12 29 CANopen Software 1 2 4 Synchronization Objects The synchronization mechanism used in CANopen is based on the producer consumer scheme One producer exists in the network that cyclically transmits the SYNC message The SYNC message contains no data The identifier for this SYNC message is specified in object dictionary entry 0x1005 This entry furthermore configures whether the device is SYNC producer or SYNC consumer Two other object dictionary entries specify the timing properties during transmission The time interval bet
96. so implemented or prepared In addition hardware and compiler specific characteristics are taken into consideration as well The API offers interfaces that can be used for expansion of device specific properties The experience of SYS TEC engineers in integrating or porting the CANopen stack in various customer applications has contributed to an expansion of the standard as well Therefore any deviations from the CANopen standard are especially identified as such Design creation and configuration of an Object Dictionary is described in a separate manual refer to L 1024 2 1 Software Structure Before the individual API functions can be explained a description of the software structure and the file structure is necessary This provides a foundation for finding your way in later implementation As a rule the CANopen stack has a divided structure for application specific and hardware specific modules The CANopen stack is divided up into individual modules With the definition of modules the CANopen stack s parameters function parameters data parameters were structured so as to be scalable A portion of the modules are to be considered as core modules and are a mandatory component in the CANopen stack Other modules are not required for setting tasks This refers mostly to CANopen functions which according to the CANopen standard can be implemented optionally or as an alternative to other functions In order to leave out individual modules w
97. t Nr L 1024 CANopen Application Layer and Communication Profile Draft Standard 301 Version V4 02 13 February 2002 CANopen Framework for CANopen Managers and Programmable CANopen Devices CiA Draft Standard Proposal 302 V3 2 04 12 2004 Interface and Device Profile for IEC 61131 3 Programmable Devices CiA Draft Standard 405 V2 0 21 05 2002 CANopen Device Profile for Generic I O Modules CiA Draft Standard 401 V2 1 17 May 2002 CAN in Automation e V 418 SYS TEC electronic GmbH 2006 L 1020e 12 Index SYS TEC electronic GmbH 2006 L 1020e 12 419 Index INDEX Abort 344 Cembin6o ete 147 UNIT assit teme I D Uo 408 CGMEMIC suceso enc beth ors 151 AMI 408 174 Application specific Layer 49 Comblbe sais c ni reis 158 Big Endian os censes 408 CCHIBIDp reas 162 Bit Rate Table does 404 oo eps oio exes 125 BOOTUP 5 ted 35 59 aa 188 Callback function C OmbMaln ie ehe 84 CcmCbEmccEvent 150 CcmMPdo 334 CcmCbEmoepEvent 156 Corm NH n 137 4 2 0 100 CEMOB 122 22 s citu quad 107 cm gSEVEnL 6
98. t TPDO 1 PDO linking can be supported by graphical configuration tools especially for more complex applications requiring many connections between TPDOs and RPDOs 18 SYS TEC electronic GmbH 2006 L 1020e 12 Fundamentals A CAN message can contains a maximum of 8 data bytes This means that when using a PDO up to 8 object dictionary entries can be transmitted in one PDO Object Dictionary Entry 1 UNSIGNEDS 1 Entry 2 UNSIGNEDS Var2 Generating the Mapping parameters Entry 3 UNSIGNED 16 Var3 Entry 6 REAL32 Var6 PDO 1 Mapping parameter Index subindex entry 3 Index subindex entry 1 Index subindex entry 2 5 bindes entry 6 entry 2 entry 6 COB identifier entry 3 Figure 3 Mapping of Object Dictionary entries into a PDO Mapping parameters are entries in the Object Dictionary RPDOs index 0x1600 0 17 TPDOs 0x1A00 0x1BFF and therefore be read via the CAN bus using service data objects SDO and if permitted if write access is enabled for this entry be modified as well The PDO mapping can be done statically In this case mapping parameters can not be changed Depending on the device profile or application specification it is also possible to change the PDO mapping of a CANopen device at runtime This is called dynamic mapping Modification of mappi
99. t is important to know which functions must be executed in which operating state This is crucial in order to attain the desired functionality Explanations of internal mechanics and cycles aid in development of an understanding of the chosen solution or its limitations Furthermore explanations are given as to which tasks must be performed by the user in order to achieve the desired function To ensure the correct function of the CANopen protocol a specific sequence must be adhered to when executing the functions Otherwise it is possible that data structures won t be present or won t be initialized whereby a function call will result in an error or undefined behavior 27 The sequence for execution of the various functions is coupled with the individual NMT state machine states This procedure is advantageous in that the state can be described in great detail The NMT state machine is defined by the standard CiA DS 301 There is a good deal of secondary literature available with hints and examples to help deepen your understanding This section provides a general description of the structure of an application The application is divided into numbered areas The following sections containing descriptions of individual modules make references to these areas in order to specify the positions that must be adapted for integration of the desired module or CANopen services 2 6 1 Selecting the Required Modules and Configuration When creating a CANo
100. that toggles between two subsequent messages The NMT masters application is informed if an answer is missing or in the event of an unexpected status Furthermore the slave can detect the loss of the masters The Life Guarding is started with the transmission of the first Life Guard message of the masters Identifier DLC 0x700 Node Address Figure 14 Response from the NMT Slave to a Life Guarding remote frame Meaning of the status byte corresponds to that of the Node Guarding message refer to Table 10 The Life Guarding supervision on the NMT slave node is deactivated if the Life Guard time object entry 0 100 in the object dictionary or the Life time factor object entry 0x100D in the object dictionary is equal to zero SYS TEC electronic GmbH 2006 L 1020e 12 37 CANopen Software 1 3 1 4 Heartbeat Heartbeat is a supervisory service for which no NMT master is necessary Heartbeat is not based on remote frames but does work according to the Producer Consumer model 1 3 1 5 Heartbeat Producer The Heartbeat producer cyclically sends a Heartbeat message The Producer Heartbeat Time 16 bit value in ms configured at object dictionary index 0x1017 will be used as cycle time between two subsequent Heartbeat messages As COB ID 0x700 plus node address is used The first byte of the Heartbeat message contains the node status of the Heartbeat producer Identifier DLC 0x700 Node Address 1 Status Byte
101. tion will return a value not equal to kCopLssInvalidNodeID Now the cyclical loop can be ended and CcmConnectToNet can be called The NMT state machine is then started with CcmConnectToNet While this called is performed the NMT Callback function within the application is called with various events Information on what needs to be done within these events is provided in section 2 6 2 4 74 SYS electronic GmbH 2006 L 1020e 12 User Layer Example Ret CcmInitCANopen amp CcmInitParam_g CcomFirstInstance if Ret kCopSuccessful goto Exit run LSS init state process until NodeId is valid do Ret CcmProcessLssInitState while Ret kCopLsssInvalidNodeld Ret CcmConnectToNet if Ret kCopSuccessful goto Exit If the node number is modified again during the cyclical execution of CcmProcess then re initialization of the CANopen layer will be performed automatically in the CCM module When this occurs the events kNmtEvResetNode kNmtEvRestCommunication and kNmtEvEnterPreOperational will be registered again in the NMT Callback function of the application SYS TEC electronic GmbH 2006 L 1020e 12 75 CANopen Software 2 6 2 4 Initializing Services and Communication Objects Service Execution In the previous step the basic data structures were created and initialized The CANopen device contains a valid node number The step that follows now links
102. tionary is defined However Object Dictionary entries are not linked to the application SYS TEC electronic GmbH 2006 L 1020e 12 73 CANopen Software tCcmInitParam MEM CcomInitParam_g void main void enable global interrupt TgtEnableGloballInterrupt TRUE copy default values to RAM CcmInitParam_g CcmInitDefaultParam g set address auf CAN Controller 1 to tCdrvHwParam tCdrvHwParam is a UNION therefore the address cannot set as const by compiler it must set by user CcmInitParam g m HwParam m McloParam m pbBaseAddr TgtGetCanBase 1 initialize first instance of CANopen Ret CcomInitCANopen amp CcmInitParam kCcmFirstInstance if Ret kCopSuccessful goto Exit Exit 2 6 2 3 Node Number Configuration with LSS When using the LSS service for configuring a node number it is important to be sure to execute the LSS state machine before switching from NMT state INITIALIZATION to PRE OPERATIONAL if the node number is invalid If the application still has no valid node numbers following execution of CemInitCANopen according to LSS specification CiA DS 305 V1 01 OxFF is defined as an invalid node number then the function CemProcessLssInitState must be called cyclically in a loop CANopen will wait until a valid node number has been initialized via the LSS service before doing this Once this has occurred then the func
103. troller C167CR with integrated CAN controller and an external CAN controller SJA1000 A hardware driver is required for each CAN controller One instance exists for each hardware driver e The target supports CAN controller e g C167CS with two integrated CAN controllers However a hardware driver with N instances is required for the CAN controller Section 2 11 describes the settings for the selection and configuration of the hardware drivers For additional information on the CDRV Module refer to L 1023 CAN Driver Software Manual 48 SYS TEC electronic GmbH 2006 L 1020e 12 User Layer 21 3 CCM Application specific Layer The application specific layer CANopen Controlling Module CCM Module controls the interaction of the individual modules The CCM layer is not absolutely necessary for implementation in the application However it provides a convenient interface for use of multiple CANopen instances and encapsulates sequential function calls of multiple API functions i e initialization definition of PDOs in functions The CCM layer contains a series of small function modules When the application is created the user can attach suitable modules or use them as models for their own expansions to the CCM layer These expansions can effect the reaction to certain events which could occur during a CANopen process In any case it is not necessary that the entire set of modules be attached to an application
104. ts bytemapping in its default setting all values gt 8 are rejected It must always be possible to answer RTR queries sent to the node regardless of TxType If the criteria in aforementioned points are met then certification should be easy Note We verify our software ourselves with the current version of the CiA Conformance Test Tool We can also perform pretests of customer devices in house 412 SYS TEC electronic GmbH 2006 L 1020e 12 CANopen Certification SYS TEC electronic GmbH 2006 L 1020e 12 413 CANopen Software 5 Glossary User Layer CiA DS 301 Framework CiA DSP 302 CiA DSP 304 Communication Profile Device Profile CiA DS 401 Object Dictionary OD Communication Object TPDO RPDO Tx Type MPDO Definition of communication profile and application layer Framework for programmable CANopen devices Framework for safety relevant communication Specification of transmission protocols communication objects data objects Specification of device specific services properties CiA Draft Standard 401 Device profile for generic I O modules The Object Dictionary OD is the main data structure of a CANopen devices for storage of all device data It serves as a binding element between the application and the communication layer Any OD entry is address via an index and a sub index Object for transmitting data between CANopen devices Communi
105. ule provides services for configuration of bit timing and module ID for a LSS slave LSSMST This module provides services for configuration of bit timing and module ID for a LSS master This module provides services for an Emergency consumer It is possible to have an Emergency producer and consumer both existing at the same time in one CANopen instance EMCP module provides services for an Emergency producer It is possible to have an Emergency producer and consumer both existing at the same time in one CANopen instance Table 14 CANopen Stack structure 21 2 Hardware Specific Layer The CDRV modules make a single interface available to the CANopen stack for various CAN controllers The special properties and peculiarities of the CAN controllers are thus taken into account in the CDRV driver Porting to a new hardware platform is enabled by creating or adapting the CDRV driver The drivers are instanceable This solution becomes interesting for targets with multiple CAN controllers There multiple CANopen interfaces can be created in order to serve multiple CANopen networks from a single application The implementation of multi channel CAN cards on the PC such as pcNetCAN PCI CAN or USB CANmodul is then possible When creating configuring the CANopen stack the following cases should be taken into consideration The target supports various CAN controllers e g microcon
106. unication objects required for that In the minimum device configuration the identifier for these communication objects must correspond to the so called Pre Defined Connection Set refer to section 1 8 The device profiles define further settings for the applicable device class The pre defined settings of the identifiers for emergency messages PDOs and SDOs are calculated based on the node address Node ID which can be in the range from 1 to 127 added to a base identifier that determines the function of the individual object After Initialization is completed the node automatically switches into PRE OPERATIONAL 12 state The NMT master will be informed about this state change with the BOOTUP message sent by the corresponding node In this state it is not possible to communicate with the node using PDOs However the node can be configured over the CAN bus using SDOs in PRE OPERATIONAL state NMT services and Life Guarding are also available in this state SYS TEC electronic GmbH 2006 L 1020e 12 35 CANopen Software The application as well as the available resources of the CANopen device determine the amount of configuration via SDO over the CAN bus For example if the CANopen device does not provide a non volatile memory to store mapping and communication parameters for PDOs and these parameters differ from the default values then these parameters must be transmitted to the node over the network after initialization is complete
107. used to for example request data from a server Communication objects are used for data exchange Communication objects are available for exchanging process and service data for process or system time synchronization for error state supervision as well as for control and monitoring of node states These objects are defined by their structure transmission types and their CAN identifier The specific parameters of a communication object such as the CAN identifier used for data transmission the transmission type of message the inhibit time or event are specified by the communication profile The interface to the application APJ is not defined by the application layer and depends the manufacturer specific implementation The transmission type defines the properties for initiating a transmission Available transmission types are cyclic and acyclic as well as synchronous and asynchronous The inhibit time specifies the time that must elapse between two message transmission before a new transmission can be initiated 4 asynchronous TPDO transmit PDO will be sent after the event time has elapsed 14 SYS TEC electronic GmbH 2006 L 1020e 12 Fundamentals The order of and the rules for a data transmission between communication objects are described by protocols download The application layer and the communication objects do not define the interpretation of the transmitted data however Interpr
108. ween two subsequent SYNC messages 15 defined in entry Communication Cycle Time 0x1006 The time interval in which the TPDOs must be transmitted at the latest after receiving a SYNC message is configured with the Sync Window 0x1007 entry For each device supporting synchronous PDOs the SYNC message has the following meaning TPDOs update the data to be sent and subsequent transmission of the PDO within the synchronization window RPDOs output the data received in the previous PDO during the most recent synchronization interval to the corresponding outputs 1 2 2 Time Stamp Object CANopen provides a mechanism that allows for synchronization of all network nodes This service is based on the producer consumer model One TIME producer exists in the network that provides the common reference time for all nodes consumers The identifier for the TIME message is defined with object dictionary entry Time Stamp Object 0x1012 1 2 3 Emergency CANopen supports the application to indicate error states over the CAN bus Two error categories can be distinguished 30 SYS TEC electronic GmbH 2006 L 1020e 12 Fundamentals Communication Error The network layer can recognize and report the following errors frequent occurrence of errors while transmitting messages bus off state of the CAN controllers Transmit buffer overflow Receive buffer overflow Loss of Heartbeat or Life Guarding CRC error in SDO block transfer
109. wing previously set standard values to be modified as needed for an application In the following examples the function AppCbNmtEvent is called as the applications NMT Callback function The examples are based on the condition that only one instance was configured When multiple instances are used then the instance parameter must be completed 78 SYS TEC electronic GmbH 2006 L 1020e 12 User Layer State INITIALIZING This state is only executed one time following a power on or reset In this state the modules Init functions such as CemInitLgs must be executed In this state all application variables have to be linked to the variable entries of the Object Dictionary After this is finished the state machine automatically goes into the RESET APPLICATION event Example tCopKernel PUBLIC AppCbNmtEvent tNmtEvent NmtEvent p tCopKernel Ret kCopSuccessful which event was called switch NmtEvent_p after power on link all variables with OD case kNmtEvEnterInitialising linking of variables for CANopen with OD Ret CcmDefineVarTab aVarTab_g sizeof aVarTab_g sizeof tVarParam break State RESET APPLICATION In this event all manufacturer specific objects from 0x2000 to OxSFFF and all device specific objects starting at 0x6000 up to Ox9FFF have been reset to their power on values Power on value refers to the default value from the Object
Download Pdf Manuals
Related Search
Related Contents
GridControl - Bosch Solar Energy descargar - Alpha Decay Sanyo VCC-HD4600 User's Manual Dataram DTM63372A memory module mains, doigts. KAM Karl Fischer Measuring water 取扱説明書 IMPLAREST C - Construnario.com Copyright © All rights reserved.
Failed to retrieve file